Hooray wrote:Re: https://sourceforge.net/p/flightgear/ma ... /36051600/Thorsten wrote: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.
So in fact 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.
Actually, 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.
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.
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.
I don't think this needs to be any more complicated than that
moving the PM talk to the public forum, because I have been thinking about this in the context of 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, e.g. 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.
And James has been working in a so called Developer Mode anyway, so why shouldn't we have a "spaceflight" mode, too: https://sourceforge.net/p/flightgear/ma ... /35693664/
James wrote:Hi,
I’ve pushed a build system change, to do the following:
- define a FG_BUILD_TYPE in Cmake, with values ‘Dev’ (default), ‘Nightly’ and ‘Release’.
(other values can be added if meaningful, eg ‘release-candidate’)
- replace the existing FG_NIGHTLY and ENABLE_DEV_WARNINGS Cmake options
- add a /sim/developer-mode boolean flag
- initialise the default value of this based on the build-type. *Right now*, the only controversial thing is that Nightly builds default to developer-mode=true.
- allow developer-mode to be forced on and off in *any* build from the command line
—developer (switches it on)
—developer=false (switch it off, for testing in a self-compiled build)
- use this to switch the severity of the SG_DEV_WARN and SG_DEV_ALERT log messages up or down
- replace all the previous compile-time conditional warnings controlled by ‘ENABLE_DEV_WARNINGS’ to be dev warnings at runtime.
- report the build type in lots of places, eg via JSON, on startup, etc
I also just updated the fgmeta build script used by Jenkins to pass (I hope!) correct values for FG_BUILD_TYPE to Cmake for our nightly and release builds, but this layer can be improved now, I guess.
Please test: the new splash-screen shows a red warning text for Nightly builds, we could also show something in developer mode if it's useful. We can also have a discussion about hiding UI elements or picking different defaults based on the developer mode; since it’s a run-time switch, we aren’t excluding anyone from contributing by hiding things in ‘out-of-the-box’ mode in release builds, is my opinion.
Candidate things to hide, more suggestions welcome:
- the entire Debug menu
- wireframe mode in Rendering settings
(and probably a few more things there)
I wil gradually review warnings for dev-mode suitability, using the ‘can an end-user do anything meaningful with this message?’ criteria, I believe Richard Harrison also volunteered to do a review of that.
Any feedback on this system is welcome, we have a whole release cycle to decide what, if anything, we change in developer-mode vs normal.
(Oh and the launcher will get an ‘enable developer mode’ checkbox in the near future)
Kind regards,
James