20,741
edits
UI Unification: Difference between revisions
Jump to navigation
Jump to search
→Goals
(→Goals) |
(→Goals) |
||
| Line 5: | Line 5: | ||
== Goals == | == Goals == | ||
Work out a sufficiently-complete, but cleaned-up, subset of PUI/XML that can be supported by all existing FlightGear UI efforts, namely: | Work out a sufficiently-complete, but cleaned-up, subset of PUI/XML that can be supported by all existing FlightGear UI efforts, namely: | ||
* [[PUI]] | * [[PUI]] (OpenGL) | ||
* [[Phi]] | * [[Phi]] (HTML/JavaScript) | ||
* [[QUI]] | * [[QUI]] (Qt5 based) | ||
* [[CUI]] | * [[CUI]] (Canvas based) | ||
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 {{fgcommand|GetAvailableWxEngines}} and {{fgcommand|SelectWxEngine}} should do the job.<ref>{{cite web | 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 {{fgcommand|GetAvailableWxEngines}} and {{fgcommand|SelectWxEngine}} should do the job.<ref>{{cite web | ||