20,741
edits
PUI: Difference between revisions
Jump to navigation
Jump to search
m
→2021
m (→2021: https://sourceforge.net/p/flightgear/mailman/message/37295586/) |
m (→2021) |
||
| Line 29: | Line 29: | ||
=== 2021 === | === 2021 === | ||
In early 2021, James did a brief evaluation of ImGUI as a possibility - he's also evaluating it in some projects at his day job. | In early 2021, James did a brief evaluation of [https://github.com/ocornut/imgui ImGUI] as a possibility - he's also evaluating it in some projects at his day job. | ||
The | The API is interesting if you’re starting from scratch and only exclusively in C++, but it’s not a great fit for how we define GUIs in FG (via [[XML]]/[[Nasal]]): there is no back door that he could find, to access the persistent state of the GUI, or build it up in a data-driven way. So making a mapping to keep our existing GUI XML working (and updating correctly) becomes a bit of a chore.<ref>https://sourceforge.net/p/flightgear/mailman/message/37295586/</ref> | ||
Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point. | Pretty much all of the FlightGear GUI is defined in XML space, except for a few oddments. Let’s say 95% at this point. | ||
Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of | Additionally, even if we were to change that for the core sim (and James' current plan is to keep the XML syntax and just extend it), the installed base of '''aircraft''' ship their own XML dialogs (eg., replacing the autopilot dialog with a custom one, or just adding their own aircraft-specific helper controls for doors / lights / cargo / whatever). So even if we found the most sublimely beautiful, intuitive, compact GUI description language in the world, we have to keep the XML syntax working as-is, for the foreseeable future. | ||
Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref> | Given this, James' intention is to replace the output side [[PUI]] but keep the front-end side (XML / properties / bindings) unchanged, and therefore backwards compatible, and simply add some new types / options / widget types going forward. This will mean we still have to deal with the slightly cumbersome XML+Nasal syntax, but, well, it’s not *that* cumbersome. <ref>https://sourceforge.net/p/flightgear/mailman/message/37296280/</ref> | ||