UI Unification
| This article is a stub. You can help the wiki by expanding it. |
| FlightGear Frontends |
|---|
|
Startup |
|
Internal
|
|
External
|
Goals
Work out a sufficiently-complete, but cleaned-up, subset of PUI/XML that can be supported by all existing FlightGear UI efforts, namely:
In particular, this means providing a migration path to get rid of huge embedded custom script blocks, so that these can be re-implemented/provided in the form of generic fgcommands, in order to make dialogs purely declarative, to have most of the logic extracted out of the UI implementation. How many properties do we have to write to to switch from AW to BW? Nothing a UI should know about. A service GetAvailableWxEngines and SelectWxEngine should do the job.[1]
This approach was agreed to sound like a really good plan forward[2]
We can use the Canvas UI route to facilitate phasing out PUI/XML in favor of Phi/Qt5 - to do that, the first step is simplifying the XML dialog files to become entirely declarative, like both, Torsten and James have confirmed more than once - once they're are purely declarative, they can be parsed and/or converted/tranformed by arbitrary tools, and for arbitrary purposes - for that to happen, the first step is havinig a parser that parses PUI/XML, which supports all its features, so that they can be mapped to other constructs (think Phi, Qt5, "CUI") - this will entail removing Nasal blobs, and introducing new tags for custom widgets currently unsupported by PUI, but emulated via Nasal, conditions and existing elements (think tabs implemented via buttons hiding PUI groups via SGConditions).[3]
Specifically, this means that UI dialogs will no longer contain any logic in the form of Nasal scripts, but that they will need to be reviewed to identify generic functionality that can be added in the form of dedicated tags for layouting, widgets, fgcommands and remote properties which can be supported by all existing, and upcoming, UI front-ends, without having to know anything about FlightGear scripting in the form of Nasal.
If scripting is to be supported sooner or later, it will also need to be a well-defined subset of ECMAScript that can be supported by all front-ends, e.g. by implementing a simple DSL and a corresponding parser for it (JavaScript and Nasal are close enough so that they could certainly share most of the code).
What is needed is an extensible file format to get rid of these constructs, so that they can be replaced with the corresponding layout/widget tags (think for tabs), as well as custom fgcommand implementations, which could then be shared among all front-ends. Sooner or later, this would end up being fully-declarative, and could be easily processed by all UIs - at which point a 1:1 Qt migration would be much less work, no matter if that involves procedural UI generation or semi-automated translation using some scripted approach. What is currently taking place in PUI/XML space is hugely problematic for anything that does not run within the FlightGear process space and that does not have access to the Nasal subsystem, and that needs to change - for features like Phi/Qt etc to work, Nasal use must be encapsulated, i.e. delegated through some kind of "service layer" that is isolated from internals.
the main UI candidates (Phi, Qt5 and Canvas) could actually benefit from each other - the Canvas route could greatly benefit from being able to use Qt5, and Canvas could greatly help clean up/simplify existing PUI dialogs. Equally, some of the ideas used in Phi could be useful for the Canvas/Qt5 approach. I don't think this has to be a mutually-exclusive thing at all - the main issue is the degree of ugly Nasal hacks in those PUI/XML dialogs; however, these dialogs can obviously be processed via Nasal and Canvas easily - so that it would actually make sense to use this opportunity to refactor said dialogs and turn into just declarative XML using tags and fgcommand/remote properties.[5]
Motivation
Note that Qt is supposed to be optional - so what do we do if Qt isn't added at compile time?[6]
If a sizable number of core developers has argued against making Qt a dependency and there's a consensus to confine its use to a GUI module, then there are legitimate concerns[7]
As far as aircraft dialogs are concerned [...] the parser has to be backward-compatible no matter what unless someone actually wants to go manually through old aircraft and fix. Also - what's the idea with Phi for aircraft access? A separate set of special dialogs aircraft-side? It's basically the same challenge.[8]
Our lowest-effort, most-visually pleasing and consistent result is going to be making both Phi and Qt UIs able to work / translate / parse the existin dialog PUI/XML syntax.
Likely with some exceptions, especially on the Phi side if Nasal is involved. The question is how practical this really is; i.e. due to the complexity of the aircraft dialogs - a solution which works with the common 90 or 95% would be good enough[9]
Adding another dependency to FlightGear is usually very controversial, i.e. the consensus was that that is not something to be taken lightly. And then again, it would require updating all of the gui definitions.[10]
Of course, it should be possible to support the current XML syntax using any toolkit, it just's a question of how hard it is.[11]
James always imagined he’d write some code to host an XML dialog (Currently done with PUI) from Qt also. The question is if that can be done keeping ‘source compatibility’ exactly with the current UI XML and Nasal interface. It probably can be, but many of the PUI widgets have really ugly APIs, especially for combo-boxes, drop-down menus and scrolling lists, where it makes sense to map a Nasal class to a Qt ItemModel, which would be more elegant and easy to work with in both Nasal and integrate on the Qt side. But obviously would mean changing the dialog sources. Of course, I think aircraft dialogs tend to be simpler, and not use the more complex PUI widgets, precisely for reasons like this, but that’s a limitation it would be best to remove.[12]
Regarding the Canvas GUI system, we could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser.[13]
Keeping the current XML format is really a requirement - improving that format, especially handling of layouts, is another task, but there's too many existing dialogs to really break compatibility.[14]
We need to keep the existing way of specifying GUI files via XML - it's a nice, declarative way of building the dialogs. Switching to an imperative system would be a step backwards.[15]
So long as we keep XML compatibility most of the current Nasal interaction with the GUI will work. There is great scope to make /better/ Nasal APIs for items such as combo-boxes and pickers, especially ICAO and radio frequency pickers, but that's all 'improving the GUI' work than can happen once we've ditched PLIB and have something hackable.[16]
Widget tags
 |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
new widgets should support customization via inheritance, i.e. along the lines of effects in FlightGear.
<ui-version>- whenever the existing markup format changes, the ui-version field must be incremented<azimuth>(course, heading, radial)<runway-select><tooltip>- for widget specific tooltips<link>- for clickable URLs<frequency><tab>- tabs<image>- to show raster images<select-date>- date picker<select-file>- file picker<scrollbar>(i.e. slider)<progressbar><tutoriallist><checklists><tapes><overlays><radiogroup><menu><menubar>
Layout tags
fgcommands
| Note This will need to be based on reviewing existing dialogs with huge portions of custom Nasal blobs to get rid of those |