Apply the device-pixel-ratio when calculating the initial position of
PUI dialogs, so they appear correctly (eg, centered) when running with
device-pixel-ratio != 1.0
The mapping from aircraft URI to name was wrong for local (non-package)
aircraft, as spotted by Thorsten Renk. Note other data (thumbnail) is
still incorrect, but another change I have pending will replace this
code anyway so only doing the simple fix for now.
Move all PUI event and rendering into a custom camera, which can be
rendered via an FBO to account for display-resolution scaling (HiDPI).
Start wrapping PUI calls in #ifdefs so PUI can be disabled at compile
time; a run-time switch is trivial now but not implemented yet.
This makes it considerably easier to reference an item from the currently selected style without having to lookup the selected style index and then use that to select the appropriate element from the styles/ tree
Updating the value takes immediately, as it did in 2017.1 and prior.
Additionally, passing —download-dir on the command-line is detected
and handled specially; the UI option is disabled, and no changes are
made to the value passed in. (The launcher does not override the value
with any value it has saved)
Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
As spotted by Thorsten, reduce user annoyance by asking about FGData
when the built-in data is acceptable. (Advanced users can use the
launcher or other options to change FGdata as normal).
When the user specified an MP server without providing a port, the
launcher would pass a malformed command line, leading the the simulator
bailing out.
(Should go to the release branch)
Add an additional visibility flag to the menubar implementations,
conditional on whether or not the menubar overlaps the window content.
(I.e for PUI but not Cocoa). This flag is linked to a new property
/sim/menubar/overlap-hide, which the renderer drives off the splash-
screen visibility.
On Windows, use:
- QtFileDialog if FG was built with Qt support;
- PUIFileDialog otherwise.
Behavior on other platforms is unchanged. This change is motivated by
the fact that some Windows users have reported[1][2] weird,
non-deterministic behavior of WindowsFileDialog and unfortunately, no
one seems to be willing and able to fix the problem. The Qt
implementation comes for free and should be quite robust. Of course, if
someone wants to maintain the WindowsFileDialog class again, the change
can be reverted.
See discussion at [3].
[1] https://forum.flightgear.org/viewtopic.php?f=25&t=31945
[2] https://sourceforge.net/p/flightgear/mailman/message/35761650/
[3] https://sourceforge.net/p/flightgear/mailman/message/35759819/
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().
Instead of the two vectors we manually composed, used a single unified
vector of structs to store delegate information in the model. This
simplifies the logic for tracking the active variant (and in the future,
thumbnail).
Move the existing aircraft history to a more obvious place, and follow
the same pattern for the complete location history. This makes restoring
a previously used configuration much simpler.
It is not needed anymore to hardcode the number of lines of
$FG_ROOT/Airports/apt.dat.gz. The new method, which relies on
SGPath::sizeInBytes() and sg_gzifstream::approxOffset(), works as well
for the other dat files.
Add a new NavCache rebuild phase, REBUILD_READING_APT_DAT_FILES, since
the process is now made of two parts.
Rename NavDataCachePrivate::getDatFilesPaths() to
NavDataCachePrivate::findDatFiles(), because it now returns a
DatFilesGroupInfo (new struct) instead of a PathList. For the same
reason, rename NavDataCachePrivate::aptDatPaths to
NavDataCachePrivate::aptDatFilesInfo. Adapt signatures, etc.
This requires up-to-date SimGear and FGData.
Load every file matching the pattern NavData/apt/*.dat[.gz] inside each
scenery path. These files are loaded in the same order as the components
of globals->get_unmangled_fg_scenery() they reside in. Inside a given
component, the order is determined by pathSortPredicate() in
simgear/misc/sg_dir.cxx (lexicographic order at the time of this
writing). For compatibility with existing scenery,
$FG_ROOT/Airports/apt.dat.gz is also loaded last.
The idea is that such files will have the same precedence order as the
globals->get_unmangled_fg_scenery() scenery components they come from.
This commit doesn't handle this fully yet, though: it blindly loads all
these files. A future commit will ensure that no airport is loaded twice
due to overlapping apt.dat files. This commit however handles all the
logic of navdata cache rebuilding when the list, the order of apt.dat
files, or any of their timestamps changes.
Although only apt.dat files receive a new treatment in this commit, the
changes to NavDataCache.[ch]xx are already generic so that extension of
this method to fix.dat, nav.dat, etc. will require almost no change to
NavDataCache.[ch]xx (however, changes will probably be needed in the
various loaders: in fixlist.[ch]xx, navdb.[ch]xx, etc.).
src/Navaids/CacheSchema.h:
- increment the SCHEMA_VERSION by 1. This ensures among others that if
someone uses a FlightGear version posterior to this change with
new-style scenery (having NavData/apt/*.dat[.gz] files inside
scenery paths), then goes back to a FlightGear version anterior to
this change, his NavCache is rebuilt ignoring the in-scenery-paths
NavData/apt/*.dat[.gz] files, as expected with the old FlightGear
version.
src/Navaids/NavDataCache.cxx:
- NavDataCachePrivate: replace aptDatPath (SGPath) with aptDatPaths
(PathList).
- NavDataCachePrivate::getDatFilesPaths(): new method that returns the
list of $scenery_path/NavData/<type>/*.dat[.gz] files found inside
scenery paths (where <type> is one of 'apt', 'fix', etc.), plus the
historical file (e.g., $FG_ROOT/Airports/apt.dat.gz for the 'apt'
type).
- NavDataCachePrivate::areDatFilesModified(): new method that tells
whether any of these files (for a given type) has changed since the
last NavCache rebuild, or if their ordered list has changed.
- NavDataCachePrivate::isCachedFileModified(): minor changes.
- NavDataCache::updateListsOfDatFiles(): new method that updates the
lists of dat files used for NavCache freshness checking and
rebuilding, i.e. currently sets/updates d->aptDatPaths using the new
method d->getDatFilesPaths(), and d->metarDatPath, d->navDatPath,
d->fixDatPath, d->poiDatPath, etc. as usual. This method will be
useful for instance in the built-in launcher after updating scenery
paths and before calling NavDataCache::isRebuildRequired().
- NavDataCache::NavDataCache(): use
NavDataCache::updateListsOfDatFiles() to initialize d->aptDatPaths,
d->metarDatPath, d->navDatPath, d->fixDatPath, d->poiDatPath, etc.
- NavDataCache::isRebuildRequired(): use
NavDataCachePrivate::areDatFilesModified() instead of just checking
$FG_ROOT/Airports/apt.dat.gz.
- NavDataCache::doRebuild(): load all apt.dat files listed in
d->aptDatPaths, instead of only $FG_ROOT/Airports/apt.dat.gz. Write
their ordered list and timestamps in the NavCache.
src/Navaids/NavDataCache.hxx:
- declare the new method NavDataCache::updateListsOfDatFiles().
- NavDataCache::DatFileType: new enum with values DATFILETYPE_APT,
DATFILETYPE_METAR, DATFILETYPE_AWY, DATFILETYPE_NAV,
DATFILETYPE_FIX, DATFILETYPE_POI, DATFILETYPE_CARRIER and
DATFILETYPE_TACAN_FREQ. Maybe some of the corresponding files won't
have to be moved to scenery paths, but simply listing them in the
enum doesn't change how they are dealt with. Those for which
per-scenery-path locations doesn't make sense can just be removed
from the enum.
- NavDataCache::datTypeStr: new static string_list giving an
std::string such as 'apt' for each value of the
NavDataCache::DatFileType enum.
- NavDataCache::defaultDatFile: new static string_list giving a path
(relative to $FG_ROOT) to the historical/default file for each value
of the NavDataCache::DatFileType enum.
src/Airports/apt_loader.cxx and src/Airports/apt_loader.hxx:
- always include a path to the apt.dat file being processed in log
messages, since they can now apply to many files;
- be clearer about code 99: it should normally be at the end of
apt.dat files, but technically, it is not an EOF;
- use the expression "row code" consistently with the apt.dat format
spec (for now: only in places where there is another change to do).
src/GUI/QtLauncher.cxx and src/GUI/QtLauncher_private.hxx:
- turn QtLauncher::setSceneryPaths() into a static method and call it
in runLauncherDialog() before instantiating NavDataCache, so that
NavDataCache::updateListsOfDatFiles() (called from NavDataCache's
constructor) can see all configured scenery paths.
Bypass the options system to set location from the launcher; this
allows the same code to be used in-sim for repositioning, while
keeping compatibility with other repositions approaches.
Remove uses of .str(), .c_str() and some other methods of SGPath.
Pass SGPath directly where possible, or explicitly convert to the
appropriate 8-bit encoding.
Tolerate the case where a URL matching the exact FG version is
not found; lookup a generic URL, in the hope it supports our
version (additional changes will make this more likely)
------------------------------------------------------------------------
If no aircraft is selected in the launcher, the routine
AircraftItemModel::indexOfAircraftURI is called with an empty QUri,
triggering a warning in the terminal.
This commit removes such warning by ignoring QUris with empty schemes
(the routine still returns an invalid index).
osg::texture2D changes GL_UNPACK_ROW_LENGTH, which fntLoadTXF is not
prepared to deal with. Reset the value back to 0 before loading +
caching TXF fonts on the PLIB side.
When set on the command line, will be used for aircraft packages. When
set in the Qt launcher, will also be used for aircraft downloads at
all times.
When changing the path in the launcher, the set of aircraft catalogs
is refresh automatically. Note the default catalog may need to be
re-installed.
- Only clear the OSG ‘pose as standalone’ flag when we really show
a dialog, as opposed to when we /might/ show.
Tested:
- Qt build using launcher
- No Qt build
- Qt build but launcher not requested
- Use setlocale() to ensure consistent handling of locales and
string handling irrespective of whether or not QCoreApplication
is invoked. Forces a the C locale for numerics and collation,
since many pieces of FG assume this.
I didn’t know about this feature when doing the original CMake files,
we can use this to target header-file includes more precisely.
(Probably more cases exist that can be changed from global to target-
specific includes)
- add a button to the main dialog, explaining how to adjust the
fg-root path via the GUI
- tweak the GUI flow to support explicitly changing the path even
when the default path is acceptable.
- change launcher to examine the scenery paths and hence load
ground-net files for airports to populate parking data.
- refactor ground-net XML parsing to use FGGroundNetwork only, not
AirportDynamics.
- change parenting of GroundNetwork to Airport, since it contains
immutable data now.
- remove some global headers from AI headers, to avoid pollution
- change how ATC owns the ‘player’ FGAIAircraft so reset works
- ensure AIAircraft controllers are cleared on unbind for reset
As QApplication only stores a reference to argc, it may crash if
the argc passed to it goes out of scope. (One way to trigger this
is to pass an invalid --fg-root, triggering an initApp call from
Options::setupRoot.) Copy argc to prevent this.
The old Mac launcher doesn’t work on Yosemite, add a tiny
Qt-based launcher inside the main process (no need to fork /
exec) which runs before the OSG window is created.
Will be merged for 3.4, hopefully with no impact on other
platforms.
Calls to updateValues can cause nested calls invalidating
the char* passed as argument, if retrieved from a
SGPropertyNode.
Probably SGPropertyNode should also be modified to return
a std::string instead of a pointer to an internal buffer.
- no dependency on libJpeg or Simgear
- no duplicate rendering of the scene (uses a draw callback)
- supports other image types, eg PNG
- threaded so doesn't block the main loop ever
By Gijs with additions by James. Menubar is disabled at present
since it's not usable and potentially inferior to other solutions,
but committing the code so it doesn't rot.
Restarting the GUI could cause Cocoa menus to misbehave, due to
destruction behaviour of SGBinding. Use new clear() helper in the
short term to work around this.
In threaded OSG drawing, MapWidget::draw runs in the render
thread context, but touches lots of main thread state. Move most of the
work to an update() helper run on the main thread instead, so draw()
mostly makes pure GL calls.
(This is a fix for 3.0, the real solution is to migrate to a
Canvas-based map and GUI)
Write PID file to FG_HOME, use this to detect multiple launches.
When this situation is detected, set a marker property and place various
objects into read-only mode, such as the NavCache and TerraSync.
PID file is created using open+unlink semantics on POSIX, and
DELETE_ON_CLOSE on Windows, so it will be removed when fgfs exits,
even if killed or crashes.
This allows us to display a platform-native dialog for problems
which occur early in startup (before we can show a PUI/Canvas dialog).
In particular this improves feedback where FG_HOME, FG_DATA or
aircraft selection is wrong, all of which happen very early in startup.
Adding a spherical projection mode which will work at the poles and
+180/-180 line correctly. Not yet enabled since it has other issues to
be addressed.
Ensure all FGPositioned related functions return SGSharedPtr
instead of raw pointers to allow automatic conversion to
nasal ghosts without custom helper functions.
This adds the framework for platform cursor implementations; Windows and X11 to be done.
It also extend the mouse-input code to generate hover events suitable for driving tooltips.
Note there should be no visible functionality change from this commit, since everything
is inactive until fgdata changes are made.
