Startup Modes
| This article is a stub. You can help the wiki by expanding it. |
Background
|
|
We should better come to prepare for a scenario where the majority of how to interact with an aircraft resides aircraft-side, not FGData-side, and that FGData only provides default templates for the less complex craft.
Worth keeping in mind when thinking about a new UI...[1]
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.
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, for example Vostok?), while renaming menubar.xml to something like default-menubar.xml or airplane-menubar.xml.
This would free up quite a bit of UI space for any spacecraft, and not clutter up the default menubar with other irrelevant stuff.
It would also allow us to review the default menubar to better classify certain elements according to the use-case/aircraft they have in mind - for instance, jetways may make little sense for GA aircraft or helicopters ?
Speaking in general, this is really about introducing dedicated "modes", depending on the kind of aircraft people are using - and given that we have been supporting cars, trucks, motorbikes and even vessels, it may not be all that far-fetched to think about having other modes.
Problem
There's a hard-coded assumption in the menu how people are supposed to interact with aircraft systems.
That worked fine as long as aircraft were 'simple' and maintainers used generic structures for everything, but these days aircraft are growing in complexity and that's no longer enough for the upper end of the distribution (for which the A-320 is an example).
For instance, I don't want a binary 'working / failed' failure system - I usually have an idea what happens if a component gradually fails or what alternative failure modes exist and want to implement that (for instance, thrusters can not only fail off as in refuse to ignite, they can ignite but not provide full thrust or they can also fail on, i.e. refusing to extinguish).
I don't want a generic INS, I have a detailed description of drift rates, calibration and how the three systems are merged together and I want the Shuttle IMU system.
And so on - that's the driving force here - the hard-coded standard way how you're supposed to interact with aircraft is insufficient if you look at the details of how a more complex aircraft actually works.[2]
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, in essence 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.
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 is 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.
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.[3]
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:
- Headless (troubleshooting/debugging)
- Flight-sim (default)
- Spaceflight
- Marine
- RC
- Combat (think Bombable)
Furthermore, this provides a nice and clean way to also better formalize existing features and use-cases, such as:
- Dual Control
- Master/slave setups (think FSWeekend/LinuxTag)
Implementation
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.
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)keyboard.xmlmouse.xmlmenubar.xml
(and possibly even options.xml)
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.
References
| References |