Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Developer Mode

From FlightGear wiki
Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.

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]