We now show paths in ‘view command line’ and set them through the
standard mechanism. Re-ordering the paths also notifies the rest of
the system correctly.
- Rename fatalMessageBox() to fatalMessageBoxWithoutExit(). This should
prevent the kind of bug that prompted this set of changes: someone
calling fatalMessageBox(), assuming the program would stop at that
point, whereas in reality it did not.
- Add new function fatalMessageBoxThenExit(). This is not vital of
course, but allows one to spare one line here and there and to apply
the DRY principle for such fatal exits.
- Replace every existing call to fatalMessageBox() with one or the other
of the two new functions. Improve formatting along the way. This
fixes a few bugs of the kind explained above.
This reverts commit 9e6a3ebc6b ("Make
fatalMessageBox() end with std::abort() and declare it [[noreturn]]").
After reflexion, it seems better to let fatalMessageBox() return,
because there is existing code that appears to be relying on this aspect
to do some work after having called fatalMessageBox() (cf. main() in
bootstrap.cxx). Also, the way of exiting from fatalMessageBox() after
commit 9e6a3ebc6b (std::abort()) was probably too brutal for a
controlled exit---as opposed to a terminate handler.
When adding a scenery path in the built-in launcher, accept folders
containing any of the new directories populated by osm2city. Also try to
improve the message that is displayed when the sanity check conditions
for the added scenery path aren't met (cf. discussion around
<https://sourceforge.net/p/flightgear/mailman/message/35716946/>).
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
- Add an optional argument to flightgear::initApp(): doInitQSettings.
This argument defaults to true, preserving initApp()'s behavior in
this respect. If this argument is set to false, FGGlobals doesn't have
to be initialized.
- New function flightgear::initQSettings(), called by
flightgear::initApp() when its 'doInitQSettings' argument is true.
This allows initializing the QSettings exactly when it is needed.
- New function flightgear::checkKeyboardModifiersForSettingFGRoot().
The code it contains used to be run from initApp(), which is
undesirable because:
1) initApp() is not only called at FG initialization (fgMainInit()),
but also from QtMessageBox(), from QtFileDialog::exec() and twice
from Options::setupRoot(). However, checking the Alt and Shift
modifiers to set 'fg-root' in QSettings to the special value
"!ask" only makes sense in fgMainInit(), not in these other
places.
2) This code relies on the QSettings to be set up, and therefore on
FGGlobals. Thus, freeing initApp() of its dependency on FGGlobals
requires splitting this keyboard modifiers checking code out of
initApp().
