Changes

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 "spaceflight-menubar.xml" and add sensible stuff there (probably in collaboration with other folks working on spacecraft, e.g. Vostok ?), while renaming menubar.xml to something like "default-menubar.xml" or "airplane-menubar.xml".

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.

== Ideas ==

== Ideas ==

this could be accomplished by removing the generic stuff from the default menubar.xml and explicitly adding it at the aircraft level on an opt-in basis, i.e. via -set.xml which would load the "default" (generic) AP/route manager and failure manager components. More sophisticated aircraft would obviously use their own UI dialogs.

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's just a matter of commenting out problematic defaults from menubar.xml and explicitly re-adding them at the -set.xml level if people want to use those.

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)

* Headless (troubleshooting/debugging)

* flight-sim (default)

* Flight-sim (default)

* spaceflight

* Spaceflight

* marine

* Marine

* RC

* RC

* combat (think Bombable)

* 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)

* Master/slave setups (think FSWeekend/LinuxTag)

== Implementation ==

== Implementation ==

The implementation is surprisingly straightforward, as long as it's based on the approach used by Torsten and Florent to implement the [[Addons]] system, and it would be in line with the method used by Erik to implement [[Graphics Card Profiles]] support.

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, e.g. :

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.