FlightGear Qt launcher: Difference between revisions
Red Leader (talk | contribs) m (Minor formatting changes) |
(Add screenshot) |
||
| Line 1: | Line 1: | ||
[[File:Qt launcher for FlightGear 3.5 on Windows 7.jpg|thumb|The aircraft page of the Qt launcher for FlightGear 3.5 as rendered on Windows 7.]] | |||
== Announcement == | == Announcement == | ||
Revision as of 13:37, 14 March 2015
Announcement
James Turner is currently prototyping (at the suggestion/encouragement of Curt, Torsten D & others) a GUI integration for FlightGear based on Qt 5. This would overlap some areas other folks are working on, so we felt it best to make an announcement to avoid anyone expending their time on areas that might be affected[1].
This will be an in-app launcher for Mac initially, based on Qt5. Primarily, because the old Mac launcher doesn’t work on Yosemite, so we are adding a tiny Qt-based launcher inside the main process (no need to fork / exec) which runs before the OSG window is created, this will be merged for 3.4, hopefully with no impact on other platforms.[2].
All of this would be a QtQuick 2 GUI, not a Qt widgets GUI. If you don’t know what that terminology means, don’t worry about it, the quick answer is it works the same ways as Canvas does at present (rendering to OpenGL).
For now, 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).
Expect to see a test branch in Git in the next month or so, and hopefully something usable for 3.6. Note that even in this (slightly optimistic) case, there will be some limitations – e.g., multi-window setup will not work in Qt builds without further work. The PLIB code will remain so hopefully it can be a gradual transition[1].
Some code James has written in the 2014 will be obsolete, e.g. the native message box and menubar code. 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)[1].
Background
There is currently heavy activity towards a new UI. There will be the HTML5 based version, TorstenD is currently working on and an internal implementation based on well supported libraries using Qt5 (which James Turner is working). The parallel development of HTML and Qt based UI happens by intention and is not the result of missing coordination[3]. Most likely, both will use a common service layer to provide necessary data[4].
The Qt5 stuff is currently only enabled for the Mac/OSX platforms because the corresponding launcher there had to be discontinued (well its dependencies got phased out by Apple) - and shouldn't be used anywhere else (yet)[5].
For the time being, Qt is only needed for the launcher feature, which is automatically disabled if it is not found[6]. If CMake does not find QT5 then it skips the QT launcher compilation[7].
Related to Qt, up to now - only a simple replacement for the Mac Launcher has been introduced. This is not related to the internal user interface of FlightGear, at least for now. 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[8]
The launcher is not run by default, this is because it was created as a Mac only solution. We need to have the discussion if it should become the default launcher for Windows (Linux and other Unixes are less relevant, it’s up to the distribution packagers).
You can test the launcher by passing the --launcher argument, or setting the $FG_LAUNCHER environment variable. These options exist to allow a Windows shortcut, .desktop file on Linux or the app bundle’s Info.plist to set the value when started from the GUI.
And if you run fgfs via the command line with some options, you don’t get troubled by the launcher.
Note the launcher on next will be in flux shortly as James will add some new features - support for the aircraft package manager especially, and for specifying some directory locations to support "code only" nightly builds which use an existing FGData download[9].
However, the upcoming FlightGear 3.6 release is likely to contain an integrated, hard-coded, launcher based on Qt5 to work around this issue (of the mac launcher no longer working)[10], because James Turner is prototyping a Qt5 cross-platform GUI [11].
Once we have a built-in Qt launcher that's shipped by default on Mac it will probably be used on other OS in the coming release. FGRun will be gone by then, FGRun will be gone with the next release of FlightGear, in favour of a built-in launcher.[12].