Difference between revisions of "FlightGear Qt launcher"
|Line 556:||Line 556:|
[[Category:Core development projects]]
[[Category:Core development projects]]
Revision as of 15:32, 24 June 2018
|This article may require cleanup to meet the quality standards of the wiki. Please|
The aircraft page of the Qt launcher for FlightGear 2018.2 as rendered on Windows 10
|Description||Integrated launcher for FlightGear|
|Status||Under active development|
|Changelog||flightgear/flightgear/next/src/GUI log view|
The Qt launcher is an integrated launcher for FlightGear, replacing FGRun in the official distributions as of version 2016.4. Initially designed as a stop-gap solution in FlightGear 3.4 for the problem of support for the old FlightGear Mac launcher ending with OS X Yosemite, it has become FlightGear's main launcher for all platforms, and is shipped with all official FlightGear releases (however, users building from source may need to separately configure/rebuild FlightGear). In addition, this was also motivated by the plethora of 3rd party GUI launchers/frontends developed by numerous contributors over the years .
As for why the change, because the old one was Windows-only - the Qt5 thing works for Mac and Linux as well and allows to do things OS-independently, which is really conceptually superior as we don't need to deal with dedicated Win, Mac and Linux issues.
James Turner (primarily) is working on developing a built-in launcher which is intended to completely replace fgrun. This new launcher is pretty mature, runs nicely on every supported OS, and is already available in the current release. Fred B. (who was the primary developer for fgrun hasn't been involved with FlightGear for quite some time, and fgrun is built on a pretty old gui library called "fltk". Any changes that have been made to fgrun in the past couple years have been band-aids by people just trying to keep it limping along with modern os updates, newer compilers, newer osg libraries, etc. There will come a time (probably fairly soon) where we will stop supporting, compiling and distributing fgrun with FlightGear. (Fgrun of course will always exist and anyone can compile it and use it and maintain it if they wish, it just will stop being distributed with the core FlightGear package in favor of the newer launcher.)
The longer term goals include (1) improving the process for aircraft authors' work to be included in the default distribution, and b) make it easier for groups like FGUK to integrate their own hangars into the Qt launcher aircraft management tools. For developers who wish to opt-in, being part of the default distribution would offer far wider exposure of your work. From an end user perspective, this will provide an easy/integrated point and click way to install (and update) the aircraft they are interested in. An aircraft author (or 3rd party hangar maintainer) can publish an 'addon' url that is copy/pasted into the add on page of the Qt launcher and all the new aircraft show up immediately. James has done some really nice work on the Qt side to pull all this together for the end-users. This will be another step forward in the larger process we laid out a while back. 
The ultimate goal is to make it easy for hangar maintainers to distribute and integrate their work with the 'new' flightgear launcher (which has now been around long enough that it's hard to call new.) James's aircraft catalog system makes aircraft searching, selecting, and updating really easy and seamless for the end users. Aircraft [hangar] maintainers simply publish their catalog.xml (which is generated by the script.) A side effect is this system moves us away from dependency on fgaddon (or other even more massive repositories) and promotes smaller and more focused 3rd party repositories and a higher degree of decentraliation and scalability.
History and status
In October 2014, Apple released OS X 10.10 Yosemite. Unfortunately, one of the frameworks the old FlightGear Mac launcher relied upon, called , was removed, making it incompatible with OS X Yosemite. James Turner started work on a solution for the then-upcoming 3.4 release. He added a simple built-in launcher using Qt, run before the main window would be created. It was released with FlightGear 3.4 as a Mac-only feature.
After FlightGear 3.4, it was decided to that this temporary Mac-only launcher would be developed into a replacement for FGRun and that it would become part of the plan for updating the FlightGear user interface. In FlightGear 3.6, it became available for all platforms, and has continued to be developed, enhanced, and refined.
As of May 2016, the Qt launcher is under active development. This includes the adding of new features, fixing bugs, and refining existing features.
As of mid 2016, the Qt UI is now also available at runtime; however, this needs a lot of testing, but aircraft can be installed / changed and location adjusted from within the sim. After some number of times the sim will crash.
The Options which don't work are things like setting scenery / aircraft paths, and initial position, because those interfere with the values the launcher is passing itself.
As of version 2016.4, FGRun has been removed from the official distributions.
See QtQuick use in FlightGear for the main article about this subject.
In accordance with the FlightGear 4.xx Roadmap, FlightGear's current graphical interface (based on the PUI library of PLIB) will be replaced by one based on Qt. In addition, a browser-based UI (called Phi) will continue to be developed in parallel. This will result in the following user interface:
- Qt launcher
- Internal UI based possibly with Qt/Canvas integration
- External browser-based UI (Phi)
However, it should be made clear that Qt will always remain an optional dependency.
As of 05/2017, James is still very much undecided about which technology to use for in-sim GUI, he is somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is James is fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy his ideas about how simple + robust such an API should be, James needs to evaluate if the current API can be improved or needs to be drastically changed. The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes him nervous about multi-window setups and other more esoteric OSG configs.
To run the launcher:
- Microsoft Windows users can double-click the FlightGear <version> icon on the Desktop or click on Start -> All Programs -> FlightGear <version> -> FlightGear Launcher;
- OS X and Linux users must open a terminal and run fgfs with the option
$ fgfs --launcher
|Note The launcher is an optional feature for the reasons explained below in the Dependencies section. As a result, if you are on Linux and have installed the version of FlightGear provided by your distribution, it might not be available because the packagers might have not enabled it. In that case, ask your distribution to enable the feature.|
Enabling console display on Windows systems
To enable console display on Windows, right-click on the FlightGear shortcut on the Desktop and click Properties. In the Target box under the Shortcut tab, add --console at the end and click OK.
Aircraft/TerraSync download directory
As of FlightGear 2016.2, the location used by the launcher to store downloaded aircraft and TerraSync scenery can be specified in the Add-ons tab. Specifying the TerraSync download directory manually has, thus, become unnecessary.
- the Registry on Microsoft Windows;
- ~/Library/Preferences on OS X;
- the default preferences location on Linux (usually ~/.config/FlightGear/FlightGear.conf).
Preferences can be reset to their default values by holding down the Alt key while starting the launcher.
There is 100% agreement that FlightGear will never require Qt, the intention is we’re adding integrated convenience features but the command line / shell environment won’t change and the default mode of ‘fgfs’ even in a Qt-enabled build is unchanged. You need set an env var or pass an argument to get the launcher, even if the feature was selected at compile time. We have the advantage that the Windows and Mac pre-built builds, it’s easy to ensure Qt is available, and those users are less likely to want complex command-line control than Linux users.
And even if Qt is selected at compile time, it will still be possible to disable it at run time. That’s important because /initially/ it’s likely that some window-setup features won’t work when using Qt. Especially the multi-window options for handling different projectors side-by-side.  When the launcher was introduced, there were significant divergences of opinion regarding whether it was appropriate to require the dependency on Qt; the core developers concluded that it was undesirable, unless it had a specific benefit. Since, for the time being, Qt is only needed for the launcher, it has been made an optional dependency, and people can continue using other frontends should they wish so.
-- Qt launcher enabled, checking for Qt 5.1 / qmake CMake Warning at CMakeLists.txt:303 (find_package): By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5", but CMake did not find one. Could not find a package configuration file provided by "Qt5" (requested version 5.1) with any of the following names: Qt5Config.cmake qt5-config.cmake Add the installation prefix of "Qt5" to CMAKE_PREFIX_PATH or set "Qt5_DIR" to a directory containing one of the above files. If "Qt5" provides a separate development package or SDK, be sure it has been installed.
As of May 2015, the Qt launcher is the default on Microsoft Windows and OS X: in the case of Linux, it's up to the distribution packagers whether to include it or not.
If, how and when the internal GUI can leverage Qt is under investigation and in such an early state that those responsible preferred to not announce anything yet. If this ever happens, this will be discussed on the mailing list.
Segmentation faults and race conditions
|Note Also see ticket #1819, ticket #1870|
|Should installing an aircraft to the proper aircraft folder be allowed to crash the launcher if that plane has an error the launcher can detect or should maybe the launcher load and report an error somewhere visible in the launchers gui?
|Note that as the QtLauncher transitions into a full GUI to replace the PUI GUI, many of these issues will disappear, and new ones will appear. In any case, debugging a modern GUI is much harder than debugging the non-GUI parts. A basic knowledge of threading, locks, and racing is quite useful for understanding and catching these bugs.
— Edward d'Auvergne (Sep 4th, 2015). Re: [Flightgear-devel] Debug build / crash on exit.
(powered by Instant-Cquotes)
|Note Building a QT based GUI is not in any way meant to obstruct the further development of a Canvas based GUI. We did voice some concerns as to whether the need to re-implement a complete widget is worth the cost is terms of development effort. The beauty of open source is that there's more than one way to do things, however. Especially in a completely modular environment (via HLA) .|
James isn't expecting many issues integrating Canvas layers with a Qt GUI, so there is no wasted development effort there (there is the possibility to make a Canvas backend based upon QPainter, which might be a great way to use spare CPU cycles to unload the GPU, however, as Canvas rendering becomes more intensive). However, at least for the time being, the Qt5 GUI is not even available at run-time, but will be shut down after handing over control to the main FlightGear initialization routines.
Originally, one of the main motivations for adopting Canvas and using it for UI purposes was to help getting rid of PUI (our legacy GUI engine), while coming up with a GUI that would be compatible with other important use-cases (think modern MFDs showing GUI dialogs and vice versa).
In addition, the idea is to keep modernizing and unifying the 2D rendering back-end in FlightGear by getting rid of legacy GL code to hopefully use modern OSG code in more and more places. At least for now, it isn't even clear if/how and when Canvas-based MFDs may support HTML5/Qt5-based UI components or vice versa (e.g. a Qt5 based dialog showing Canvas-based features, such as a MapStructure layer or MFD instances like the NavDisplay). Unlike Canvas-based efforts like the Aircraft Center, the Qt5 effort is also adding a rather significant build-time dependency for those wanting to use the new built-in launcher.
Duplicating existing functionality
There's also the issue of code duplication and maintenance, too. As can be seen by functionality that is now getting added/re-implemented in Qt5/C++ space, despite already existing elsewhere:
As can be seen, there's currently no code reuse taking place when it comes to the Qt5-based location tab, and the Canvas/MapStructure-based airport/taxiway layers are very much superior in comparison, too (as well as being much better maintainable (living in fgdata)) - so it would make sense to work out a way to reuse existing code instead.
Once the PropertyBasedElement/CanvasElement wrappers are fully exposed to scripting space, we could easily register MapStructure as a new Canvas element for directly making the corresponding layers available to C++ code, without introducing any direct Nasal dependencies - i.e. the corresponding airports/runway and taxiways diagrams would be transparently created by Nasal-based Canvas elements, with the Qt5/C++ code only ever having to set a handful of properties (airport ICAO id, styling, range etc).
The main obstacle preventing us from doing this right now is that we're not yet Initializing Nasal early, so that the corresponding Nasal/Canvas bindings (via Nasal/CppBind) are not yet available when the Qt5 UI is running.
PLIB/PUI (legacy GUI)
See Howto:Processing legacy PUI dialogs using Canvas for the main article about this subject.
Up to now - only a simple replacement for the Mac Launcher has been introduced (and enabled by default only on OSX). This is not related to the internal user interface of FlightGear (which is mainly based on PUI and increasingly Canvas these days), at least for now.
However, the goal is to make an optional Qt dependency to replace PLIB PUI.
Except of course PUI will have to remain for some awkward use cases in the short term (aircraft dialogs, potentially). When compiled without Qt support, you’ll get a fully functional FG (i.e., Qt will never be a requirement to build FG), but without the GUI functions – which is indeed what some people want anyway (e.g., in some home cockpit setups).
Any in-sim GUI using Qt will exist in parallel to the PLIB/PUI one for at least one major release, although this may mean maintaining two sets of dialogs, unless the XML-translation-tool is good enough that we can use it at run-time for aircraft dialogs.
Expect to see a test branch in Git in the next month or so, and hopefully something usable for 3.6. The PLIB code will remain so hopefully it can be a gradual transition.
|At least for the time being, PUI doesn't seem to become obsolete anytime soon, according to James Turner's continuing preference to hack/extend and maaintain custom PUI widgets:
http://sourceforge.net/p/flightgear/mailman/message/34747786/ This observation is also in line with numerous PUI related commits that he made despite his ongoing Qt5 work: http://wiki.flightgear.org/Canvas_GUI#PUI_WidgetsFor a more recent example, look at the waypointlist commits that are using neither Qt5, Phi or Canvas at all: http://sourceforge.net/p/flightgear/flightgear/ci/846fd2
— Hooray (Jan 9th, 2016). Re: Can't install FGRun package (+ rant about Qt5 launcher).
(powered by Instant-Cquotes)
Python in FlightGear
Cross compiling using MinGW64
See Building FlightGear - Cross Compiling for the main article about this subject.
As of May 2014, the dependency on Qt 5.1 makes it impossible to cross-compile the launcher using MinGW64, as the MXE project does not have makefiles for that version of QT.
|The problem is the initialisation sequence. The QtLauncher starts before the 'dynamic airports'. Therefore the park positions are not available (unless they have been added to the NavDataCache by previous runs of FG, and the NavDataCache is not rebuilt).
— Edward d'Auvergne (Oct 22nd, 2015). Re: [Flightgear-devel] FGFS Launcher -->selecting Parkpositions ???.
(powered by Instant-Cquotes)
Proposition for the new content / organisation of the QtLauncher.
rem: each first-level item in the following list represents an icon in the vertical icon box, on the left side of the mainwindow. The sub-level items could be organised by tabs, groups, panels in separated pages.
rem2: some of these items don't exist yet, or are unstable. This list could be a starting point to develop some ideas...
- (ex: tutorials, carrier mission, volcanic ash mission, engine failure mission, military mission, fire mission...)
- Rem: selecting Mission disables the Aircraft/Location/Time/Weather icons
- Custom Flight Plan
- UFO (sandbox mode)
- Saved flights
- Fly! = starts the simulation.
- Search box + List of the installed aircrafts
- Rem: maybe better to download the addons manually and copying them in the add-ons directory?
- Properties box (description, author, copyright, date, version, website, stable or unstable) with screenshots
- Option: Hide aircraft based on completeness
- Aircraft settings
- (ex: weight, CoG, crew and passengers, bagages, fuel)
- Enable System Failures
- Enable Crash/Damages
- Autostart engine(s)
- HTML Aircraft documentation
- Search box + List of the installed aircrafts
- Search box + List of the installed locations
- 2D Map
- Show/hide roads, rivers, Show/hide heightmap, zoom in/out...
- Show the downloaded locations (with option to restrict the list to the downloaded scenaries only)
- Show the points of interest
- Show the NOTAM
- Show the CTA, CTR and restricted areas
- Toolbox to prepare the Flight Plan (departure, arrival, route, distance calculation, fuel calculation)
- Enable NOTAM (with a select list of NOTAM)
- Season (local or custom)
- Hour/Time (local or custom)
- 2D Map (satellite weather map, forecast charts)
- with the flight route previsouly defined
- Basic settings: Sun/Snow/Rain/Icing/Storm
- Clouds layers
- Real online weather
- Volumic clouds generation
- 2D Map (satellite weather map, forecast charts)
- Pilot's Logbook
- Missions completed
- Replay a flight
- (default (english) or locale or custom)
- Traffic density
- Dogfighting bots
- Path settings
- Choose another FG_ROOT (default or custom)
- Choose another FG_HOME
- Choose another FG_DATA...
- Screenshots directory
- Replays directory
- Network settings
- Main switch to open/close the internet connexion
- LAN or Internet connexion settings
- IP address of the scenary server (terrasync)
- IP address of the weather / METAR server
- IP address of the aircrafts catalog server
- IP address of the multiplayer server(s) (with username / login)
- Screen settings
- Option: Fullscreen
- PHI (instructor screen)
- Port number (ex: --httpd=8080)
- Button to open the web broser "localhost:8080"
- GPU Driver options (antialiasing, shaders,...)
- Rendering method : ALS, Rembrandt...
- Sound device
- Mesh quality, Level of Details
- Textures quality
- AutoGen settings (buildings, cars, objects, trees,...)
- Procedural cities settings
- Bombable (animations, scenary damages...)
- Enable debug mode (debug menu, console, fps and stats display)
- Path to the debug logs directory
- HTML Documentation
- link to FG wiki
- link to FG website
- Build / version number
Issues and limitations
Note that even in the optimistic case, there will be some limitations – e.g., multi-window setup will not work in Qt builds without further work.