Developer Mode: Difference between revisions
Jump to navigation
Jump to search
m (https://sourceforge.net/p/flightgear/mailman/message/35692898/) |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Stub}} | {{Stub}} | ||
{{See also|Startup Modes}} | |||
03/2017: James pushed a build system change <ref>https://sourceforge.net/p/flightgear/mailman/message/35666576/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/35692898/</ref>, to do the following: | 03/2017: James pushed a build system change <ref>https://sourceforge.net/p/flightgear/mailman/message/35666576/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/35692898/</ref>, to do the following: | ||
Revision as of 14:27, 29 December 2017
| This article is a stub. You can help the wiki by expanding it. |
See also Startup Modes.
03/2017: James pushed a build system change [1][2], 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)[3]
References
| References |