A320-family development

[merspieler]

@lego refuel dialog pr is on git...please go over the todo list...

my hands are tied regarding the fuel system (still running 2019.1.1

[Thorsten]

my hands are tied regarding the fuel system (still running 2019.1

Do you guys need these nested tests for anything crucial? My experience is that it's quite easy to pull them apart, so it seems at the moment using this feature harms you more than it does you good...

[legoboyvdlp]

They are used extensively throughout the system where there are AND statements and then OR statements. It would be possible to do without, probably, but it would take far more lines of code and multiple switch statements per fuel pump / valve.

[Hooray]

would be good to switch away from PUI for other dialogs as well.

note that any existing PUI/XML dialogs will need to be supported either way - think about external hangars and UI dialogs in add-ons, so PUI/XML support is there to stay, whatever UI solution ends up being adopted/supported "some day", PUI/XML is going to be supported "as is" for quite some time to come.

Obviously, aircraft developers can opt to isolate themselves from anything involving PUI vs Qt vs Phi by using Canvas, but manually coding dialogs is not such a good idea in general, unless this is primarily about widget-reuse (think sharing widgets between UI dialogs and actual avionics/MFDs).

Any dialogs not using any <nasal> or <canvas> tags are going to be supported anyway, while some people have considered writing a translator to convert dialogs, this isn't a feasible option for dialogs that live elsewhere in the FG ecosystem, i.e. outside fgdata.

There is also a sizable portion of PUI/XML dialogs that are used for crucial features, despite containing Nasal/Canvas sections - e.g. the tutorial system, checklist dialogs, joystick config, tutorials or the airports dialog.

These represent several years of ongoing work by a number of senior contributors, and they are not "optional" either - so whatever non-PUI solution is adopted/supported some day, it would either have to support these legacy dialogs, or the people (person) working on the alternate UI would have to offer to re-implement those features, too

A number of folks have previously tinkered with manually porting PUI/XML dialogs, Torsten even said that he tinkered with a parser for Phi - F-JJTH began manually re-writing dialogs in Nasal using the Canvas system. Long story short, it's not a feasible path forward unless you really have a fallback mechanism in place, which basically entails supporting PUI/XML "as is" for the foreseeable future - and this has been the case for last 7 years, despite some people literally pushing for a new/different UI.

What is most likely to happen regardless of the UI stack in use, is that PUI/XML will remain supported - but that PUI/XML dialogs in fgdata/fgaddon will optionally be versioned, so that new widgets can be introduced, without being restricted by PUI - at that point, it will become possible to have version tags at the PropertyList/dialog level, so that breaking changes can be made - this will make it possible for fgdata/fgaddon developers to get rid of Nasal/Canvas sections that are currently used to work around existing PUI limitations, by introducing dedicated widgets - think a "frequency-picker", "airport-list" or tabs.

At that point, our existing PUI/XML dialogs can be converted to become purely declarative, without excessively relying on Nasal - the latter can already be accomplished by moving Nasal blobs into functions that are registered as fgcommands, at that point the UI stack becomes totally relevant - because you'd be using primarily XML and fgcommands again.

The pui2canvas parser can help accomplish that, and therefore it could even facilitate migrating to a different UI back-end, which may involve both, Qt and Phi at the same time - because those dialogs could trivially be made to work for all solutions: PUI/XML in-sim, Qt/QQ (option), Phi or Canvas

[legoboyvdlp]

Wow, that was a long post...

[Hooray]

Admittedly, it may seem long and also offtopic - but it really isn't, you only need to take a look at the history of PUI use in FlightGear and what's been "happening" in the "PUI replacement department over the course of the last 7 years" to make up your own mind - no matter if you like/dislike PUI, Qt5, Phi or Canvas - PUI/XML support in its current form is there to stay for a number of very valid reasons - nevertheless, PLIB PUI itself can definitely be phased out - and doing so by using Phi and/or Canvas may actually facilitate migrating towards Qt5/QQ2 - the first step is versioning our existing PUI/XML format, so that we can clean up existing dialogs by introducing new layouts/widgets and fgcommands, and moving out Nasal blobs into standalone library code (encapsulation), preferably by registering these as fgcommands - which conveniently are accessible to Phi, too - so these will work for Qt5/QQ2, Canvas - but also for PUI/XML "as is".

[xcvb]

Maybe it is a good idea to introduce a flag in the aircraft-set file to indicate that this aircraft is ready for PUI removal. These aircrafts could be loaded without PUI libraries but with OpenGL3 support.

[Hooray]

actually, aircraft don't depend on PUI, and they also don't "use" OpenGL 3 - at most, an aircraft may feature custom PUI/XML dialogs, but even those can be interpreted/executed by a non-PUI runtime, using Qt/QQ or Canvas - as such, aircraft using or not using PUI is basically irrelevant for the rest of the sim. Whether an aircraft uses a non-PUI GUI or not, has no effect for the time being: the rest of the in-sim UI still is using PUI. So we won't create any "incentive" by telling aircraft developers "not to use PUI" and to opt instead for "Qt/QQ, Phi or Canvas".

However, the thing is, all aircraft developers who do end up creating custom Canvas based dialogs have already figured out how to create custom dialogs and "widgets" (UI controls), so that their code could become the pillars for any Canvas-based in-sim UI, as long as it's sufficiently generic in nature, and not specific to any single aircraft or use-case (dialog).

Ideally, aircraft developers creating custom Canvas dialogs would create their own library of 2D drawing routines and UI management helpers, that don't contain any hard-coded assumptions about the aircraft or dialog - that way, the same modules could be easily reused elsewhere - once that is the case, it is a piece of cake to hook up such existing code to a simple parser that loads an arbitrary PUI/XML dialog and creates a reasonable Canvas-driven equivalent.

But other than that, the question whether PUI remains or not, should be completely relevant to aircraft developers - if they're indeed feeling restricted by PUI, they'll probably already be using Canvas anyway

[xcvb]

OK, the aircrafts do not depend on PUI, but the custom dialogs might look very bad with PHI or Qt5 and an aircraft can rely on OpenGL3 when using e.g. tesselation shaders. I thought if all the custom aircraft dialogs work well with PHI or Qt5, then it could be possible to not load PUI for this aircraft, but maybe I'm wrong.

[Hooray]

I don't think it should be of much concern to aircraft developers what UI back-end is used, it's very unfortunate that aircraft devs are so concerned about this debate - de facto, nobody can simply phase out existing dialogs, without also offering to re-implement all dialogs, or without providing a fallback solution to machine-translate/parse those dialogs in the meantime. Concerning yourselves with the PUI/Qt migration should not be an issue - using Canvas for custom dialogs because PUI is too restricted, or because aircraft devs want to reuse their MFD routines for their UI, is obviously a valid use-case, but just dropping PUI because someone is working on a different back-end, makes no sense at all - think about all those existing features that simply depend on PUI/XML and that represent years of work, nobody in their sane mind is going to offer to manually rewrite such dialogs - and even if, any aircraft dialogs living outside fgdata (3rd party hangars) will have to continue working.

OK, the aircrafts do not depend on PUI, but the custom dialogs might look very bad with PHI or Qt5 and an aircraft can rely on OpenGL3 when using e.g. tesselation shaders. I thought if all the custom aircraft dialogs work well with PHI or Qt5, then it could be possible to not load PUI for this aircraft, but maybe I'm wrong.

Last I checked, it was indeed possible to dynamically remove PUI at runtime: http://wiki.flightgear.org/Howto:Reset/ ... leshooting

But PUI is used for all of the remaining UI for the time being, i.e. the menubar, most dialogs opened via the menubar (property browser, autopilot, route manager) - once you open/use any of those, you will inevitably also have to run PUI.



It would be trivial to create a menubar using Canvas by parsing menubar.xml, the only "real" issue is that all of the localization stuff is hard-coded and not exposed to scripting space - other than that, the menubar can be re-created via Canvas pretty easily, it's just a long window without decoration with a bunch of horizontal buttons that open popups (tooltips) with a bunch of vertical buttons without decoration. I believe we had a working proof-of-concept a few years ago, and it was created by someone entirely new Nasal and Canvas.

http://wiki.flightgear.org/Howto:Making ... as_Menubar


Other than that, it's fairly unlikely that switching to Phi, Q2 or Canvas would inevitably mean that interpreting legacy dialogs would look "bad", PUI is extremely basic and archaic - you can emulate PUIs behavior with a fairly minimal amount of code.

The screen shots below show what the parser creates by automatically translating known widgets, i.e. ignoring some layouting/formatting options and the vrule/hrule tags - but again, this is the sort of (functional !) dialog that can be created without even opening/touching any XML files, it's just a piece of Nasal code that looks for a subset of known PUI/XML tags and uses a lookup table (function) to come up with a Canvas equivalent: http://wiki.flightgear.org/Canvas_PUI_Mapping

http://wiki.flightgear.org/Howto:Proces ... .26_Status




In other words, all the building blocks for a PUI-free in-sim UI have been in place for the last 5+ years - and any aircraft developer who knows how to create a PFD, ND or any other EFIS-like instrument would also be able to help contribute to such an effort, because their existing work could be used as the foundation for a rather rich, flightsim-specific in-sim UI using a back-end that is there to stay, because FlightGear happens to include Nasal/Canvas support in a non-optional fashion, without introducing new threading/windowing issues.

In the meantime, PUI doesn't have to go completely - it can coexist with PUI, because aircraft developers can create their own widgets and simply display those inside PUI dialogs, as has been done dozens of times by various people:

http://wiki.flightgear.org/index.php?title=Canvas_News

[james.b]

Hello all,

First of all, many thanks for developing the A320 - it is a fantastic achievement and I enjoy flying it greatly. I was fortunate enough to go on a tour of the Airbus wing manufacturing facility earlier in the year and have seen first hand the skill that goes into making the real thing as well!

I'm not sure if I've found an issue with one the later versions though (rev. 7) - when starting up engine 2, I get a FAULT light on the ELEC PUMP switch for the Blue hydraulic system. Looking at the hydraulic display on the lower ECAM, I can see that a have the correct 3000PSI. Turning the pump off obviously drops this - but proves that the pump actually does seem to be working. The fault remains after engine 1 start. No other faults on the panel.

Can't obviously rule out that I've done something wrong, but I've never seen this on a start up scan of the panel before I upgraded the model to the new hydraulic systems.

Thanks for your time,

James

[legoboyvdlp]

Hi,
Anyone have any evidence that the FIX / VOR / NDB layers are hidden by the respective ND being above 40 nautical miles? This makes sense to avoid long delays if you accidentally move the knob, but I can't find such a reference in the FCOM. Anyone got any information on that?

[merspieler]

Note that it IS realistic, that it takes a bit of time. During that time RANGE CHANGE or MODE CHANGE (when changing mode) is display.

You see it in this video (best i could find on a quick search...)

[legoboyvdlp]

Yes but I don't think the real world freezes completely!

I can't find any reference to a 40nm limit so will probably remove it.

[merspieler]

Can't we get the loading out of the "real world" and in a background thread?