13,208
edits
Startup Modes: Difference between revisions
Jump to navigation
Jump to search
Minor cleanup; fix double redirect
m (→Implementation) |
(Minor cleanup; fix double redirect) |
||
| Line 9: | Line 9: | ||
Worth keeping in mind when thinking about a new UI...<ref>https://sourceforge.net/p/flightgear/mailman/message/36051600/</ref> | Worth keeping in mind when thinking about a new UI...<ref>https://sourceforge.net/p/flightgear/mailman/message/36051600/</ref> | ||
For example, the shuttle/trajectory map not making that much sense in the map-canvas.xml dialog - likewise, many of the default menubar entries and GUI dialogs don't make much sense for spacecraft. | For example, the shuttle/trajectory map not making that much sense in the <code>map-canvas.xml</code> dialog - likewise, many of the default menubar entries and GUI dialogs don't make much sense for spacecraft. | ||
Thus, I think it would be easier to introduce a a dedicated | Thus, I think it would be easier to introduce a a dedicated <code>spaceflight-menubar.xml</code> and add sensible stuff there (probably in collaboration with other folks working on spacecraft, for example Vostok?), while renaming <code>menubar.xml</code> to something like <code>default-menubar.xml</code> or <code>airplane-menubar.xml</code>. | ||
This would free up quite a bit of UI space for any spacecraft, and not clutter up the default menubar with other irrelevant stuff. | This would free up quite a bit of UI space for any spacecraft, and not clutter up the default menubar with other irrelevant stuff. | ||
| Line 44: | Line 44: | ||
== Ideas == | == Ideas == | ||
This could be accomplished by removing the generic stuff from the default <code>menubar.xml</code> and explicitly adding it at the aircraft level on an opt-in basis, in essence via <code>-set.xml</code> which would load the "default" (generic) AP/route manager and failure manager components. More sophisticated aircraft would obviously use their own UI dialogs. | |||
Thus, this is primarily a matter of formalizing best practices and making sure that people understand why to use them. | Thus, this is primarily a matter of formalizing best practices and making sure that people understand why to use them. | ||
Doing so would not require any changes in terms of PUI, Qt5 or even Phi/Canvas - it | Doing so would not require any changes in terms of PUI, Qt5 or even Phi/Canvas - it is just a matter of commenting out problematic defaults from <code>menubar.xml</code> and explicitly re-adding them at the <code>-set.xml</code> level if people want to use those. | ||
If that is something that is considered too fragile or problematic for other reasons (work load caused ...), we could just as well use/support conditions (properties) in the menubar and allow aircraft to explicitly opt in/out as needed, even if just by setting a few properties using a dedicated "mode" property.<ref>https://forum.flightgear.org/viewtopic.php?f=6&t=33110&p=320574&hilit=modes+startup#p320574</ref> | If that is something that is considered too fragile or problematic for other reasons (work load caused ...), we could just as well use/support conditions (properties) in the menubar and allow aircraft to explicitly opt in/out as needed, even if just by setting a few properties using a dedicated "mode" property.<ref>https://forum.flightgear.org/viewtopic.php?f=6&t=33110&p=320574&hilit=modes+startup#p320574</ref> | ||
== Use Cases == | == Use Cases == | ||
Supporting different startup "modes" that are session-specific provides a nice way to support different use-cases, while keeping them separate. For instance: | Supporting different startup "modes" that are session-specific provides a nice way to support different use-cases, while keeping them separate. For instance: | ||
* | * Headless (troubleshooting/debugging) | ||
* | * Flight-sim (default) | ||
* | * Spaceflight | ||
* | * Marine | ||
* RC | * RC | ||
* | * Combat (think Bombable) | ||
Furthermore, this provides a nice and clean way to also better formalize existing features and use-cases, such as: | Furthermore, this provides a nice and clean way to also better formalize existing features and use-cases, such as: | ||
* [[Dual Control]] | * [[Dual Control]] | ||
* | * Master/slave setups (think FSWeekend/LinuxTag) | ||
== Implementation == | == Implementation == | ||
The implementation is surprisingly straightforward, as long as it | The implementation is surprisingly straightforward, as long as it is based on the approach used by Torsten and Florent to implement the [[Addon]] system, and it would be in line with the method used by Erik to implement [[Graphics Card Profiles]] support. | ||
We are also already using the same mechanism to support custom scenery overlays and custom aircraft directories. | We are also already using the same mechanism to support custom scenery overlays and custom aircraft directories. | ||
So, startup modes could for example be stored in $FG_ROOT/Modes, using a custom set of directories with PropertyList/XML overlays, these would take precedence over files loaded from $FG_ROOT, | So, startup modes could for example be stored in $FG_ROOT/Modes, using a custom set of directories with PropertyList/XML overlays, these would take precedence over files loaded from $FG_ROOT, for example: | ||
* defaults.xml (formerly, preferences.xml) | * <code>defaults.xml</code> (formerly, <code>preferences.xml</code>) | ||
* keyboard.xml | * <code>keyboard.xml</code> | ||
* mouse.xml | * <code>mouse.xml</code> | ||
* menubar.xml | * <code>menubar.xml</code> | ||
(and possibly even options.xml) | (and possibly even <code>options.xml</code>) | ||
This kind of setup would make it possible to easily include, and maintain, mutually-exclusive features in fgdata without adding tons of hard-coded logics/heuristics to deal with ALS vs. Rembrandt or aircraft vs. spacecraft configuration paths. | This kind of setup would make it possible to easily include, and maintain, mutually-exclusive features in fgdata without adding tons of hard-coded logics/heuristics to deal with ALS vs. Rembrandt or aircraft vs. spacecraft configuration paths. | ||