FlightGear Qt launcher: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Cross compiling using MinGW64: no longer valid, 5.12.2 is now available)
(47 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Official Core Development Effort}}
{{infobox subsystem
 
| name           = FlightGear Qt launcher
{{Infobox subsystem
| image         = Qt launcher for FlightGear 2018.2 on Windows 10.jpg
|name       = Integrated Qt5 Launcher
| alt           = The aircraft page of the Qt launcher for FlightGear 2018.2 as rendered on Windows 10
|image       = Qt_launcher_for_FlightGear_3.5_on_Windows_7.jpg
| started       = 01/2015
|alt         = The aircraft page of the Qt launcher for FlightGear 3.5 as rendered on Windows 7
| description   = Integrated launcher for FlightGear
|started     = 12/2014
| maintainers   = {{usr|Zakalawe|James Turner}}
|description = Provides an integrated GUI front-end for starting FlightGear, without requiring separate/standalone programs/tools like [[Fgrun]]
| developers     = James Turner
|status      = Under active development as of 03/2015, currently with a focus on Mac OS X.
| status        = Under active development
|maintainers = {{usr|Zakalawe}}
| folders        = {{flightgear source|path=src/GUI}}
|developers = Zakalawe (since 03/2015)
| changelog     = {{flightgear source|path=src/GUI|view=log}}
|changelog = {{Git File History|project=flightgear|path=/src/GUI/QtLauncher.cxx}}
}}
}}
{{Package Management}}
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 [[FlightGear Mac OS X Launcher|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).


{{Package Management}}
== Usage ==
To run the launcher:
* '''Microsoft Windows''': double-click the ''FlightGear <version>'' icon on the Desktop or click on ''Start'' > ''All Programs'' > ''FlightGear <version>'' > ''FlightGear Launcher''.
* '''OS X and Linux''': open a terminal and run <tt>fgfs</tt> with the option <code>--launcher</code>:<syntaxhighlight lang="shell">
$ fgfs --launcher
</syntaxhighlight>
Note that the launcher is an optional feature for the reasons explained below in the [[#Dependencies|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.


== Announcement ==
<gallery mode="packed">
<gallery mode="packed">
Qt launcher for FlightGear 3.5 on Windows 7 location.jpg
Qt launcher for FlightGear 2018.2 on Windows 10 aircraft.jpg|Aircraft page of Qt launcher in FG 2018.2 on Windows 10
Qt launcher for FlightGear 3.5 on Windows 7 settings.jpg
Qt launcher for FlightGear 2018.2 on Windows 10 location.jpg|Location page of Qt launcher in FG 2018.2 on Windows 10
Qt launcher for FlightGear 3.5 on Windows 7 addons.jpg
Qt launcher for FlightGear 2018.2 on Windows 10 environment.jpg|Environment page of Qt launcher in FG 2018.2 on Windows 10
Qt launcher for FlightGear 2018.2 on Windows 10 settings.jpg|Settings page of Qt launcher in FG 2018.2 on Windows 10
Qt launcher for FlightGear 2018.2 on Windows 10 addons.jpg|Addons page of Qt launcher in FG 2018.2 on Windows 10
</gallery>
</gallery>
As of March 2015, there is heavy activity towards a new {{Abbr|UI|User Interface}}. There will be the HTML5/browser-based version (called [[Phi]]), TorstenD is currently working on, which will only be available after FlightGear has finished booting and initializing because it is a conventional FlightGear subsystem, as well as an internal implementation based on well supported libraries using Qt5 (which James Turner is working on), which will only be available during startup, and won't be running/available later on in its current form (i.e. at run-time), the latter having a strong focus on startup-relevant settings, while the former will only be able to deal with run-time settings.


The parallel development of HTML and Qt based UI happens by intention and is not the result of missing coordination<ref>http://forum.flightgear.org/viewtopic.php?p=229445#p229445</ref>. Most likely, both will use a common service layer to provide necessary data<ref>http://forum.flightgear.org/viewtopic.php?p=229303#p229303</ref>.
=== Installing Scenery ===
 
{{#ev:youtube|lJG3lL1vLDU}}
 
=== 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 <tt>--console</tt> 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.<ref name="LauncherChanges">{{cite web
| url    = http://sourceforge.net/p/flightgear/mailman/message/35001457/
| title  = <nowiki>[Flightgear-devel] Launcher add-on handling changes</nowiki>
| author = <nowiki>James Turner</nowiki>
| date  = Apr 8th, 2016
| added  = Apr 8th, 2016
| script_version = 0.25
}}</ref>
 
=== Preferences ===
In FlightGear 2016.2 and later, the preferences are stored in ''[[$FG_HOME]]/flightgear.org/FlightGear.ini''.<ref name="LauncherChanges" /> Older versions make use of the default location used by Qt:
* 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 {{key press|Alt}} key while starting the launcher.<ref name="LauncherPreferences">{{cite web
| url    = http://sourceforge.net/p/flightgear/mailman/message/34642397/
| title  = <nowiki>Re: [Flightgear-devel] Qt launcher and phi-utility FGFS 3.6.0 RC
to 3.7.0</nowiki>
| author = <nowiki>James Turner</nowiki>
| date  = Nov 23rd, 2015
| added  = Nov 23rd, 2015
| script_version = 0.23
}}</ref>
 
== History and status ==
In October 2014, Apple released OS X 10.10 Yosemite. Unfortunately, one of the frameworks the [[FlightGear Mac OS X Launcher|old FlightGear Mac launcher]] relied upon, called {{wikipedia|RubyCocoa}}, 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.


James Turner is currently prototyping (at the suggestion/encouragement of Curt, Torsten D & others) a {{Abbr|GUI|Graphical User Interface}} integration for FlightGear based on Qt 5. The main motivation originally being that the Mac OSX launcher would no longer work on Yosemite, so an alternative had to be provided.
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.


This is overlapping with some areas other folks are working on (particularly, making the Nasal/Canvas-based [[Aircraft Center]] available during startup by [[Initializing Nasal early]]), so we felt it best to make an announcement to avoid anyone expending their time on areas that might be affected<ref name="a">http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>.
As of May 2016, the Qt launcher is under active development. This includes the adding of new features, fixing bugs, and refining existing features.


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).
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.<ref>https://sourceforge.net/p/flightgear/fgdata/ci/654a343bbb7eb51b387060515e3415e152d12c2a/</ref>


{{FGCquote
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.<ref>https://sourceforge.net/p/flightgear/mailman/message/35689137/</ref>
|1= 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.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34532040/
  | title  = <nowiki>[Flightgear-devel]  GUI questions (again)</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Oct 11th, 2015
  | added  = Oct 11th, 2015
  | script_version = 0.23
  }}
}}


== Status ==
As of version 2016.4, FGRun has been removed from the official distributions.
{{FGCquote
|1= At some point (possibly quite soon) I’ll enable a version of the Qt launcher to be triggered from the in-sim menu (but as a separate dialog), at least an an experimental feature.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34520595/
  | title  = <nowiki>Re: [Flightgear-devel] Aircraft catalog - feedback</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Oct 7th, 2015
  | added  = Oct 7th, 2015
  | script_version = 0.23
  }}
}}


== Background ==
{{Cleanup}}
In addition, this was also motivated by [[The FlightGear Front-End Situation|the plethora of 3rd party GUI launchers/frontends]] developed by numerous contributors over the years <ref>[[The FlightGear Front-End Situation]]</ref>.


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.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=291279#p291279
  |title  =  <nowiki> Re: 2016.x.x take off from carrier </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Jul 26th, 2016
  |added  =  Jul 26th, 2016
  |script_version = 0.40
  }}</ref>


{{FGCquote
|1= I’m currently extending the launcher to do in-air starts
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34618604/
  | title  = <nowiki>Re: [Flightgear-devel] Bug 1802 : start paused --enable-freeze does
not work</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Nov 13th, 2015
  }}
}}
{{FGCquote
|1= there’s some new features
* installing / updating aircraft works pretty well, multiple downloads are queued.
* start location can be any navaid or waypoint, or a lat/lon
* start offsets (bearing + distance in Nm) are supported
* navaids are tuned when starting on a runway / using a VOR - command-line box parser supports comments
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34640695/
  | title  = <nowiki>[Flightgear-devel] Launcher changes for 3.8</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Nov 23rd, 2015
  }}
}}


{{FGCquote
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.)<ref>{{cite web
|1= Please test and report any other bugs or possible improvements, so this is robust and idiot-proof for 3.8.
   |url    = https://forum.flightgear.org/viewtopic.php?p=293518#p293518
|2= {{cite web
   |title  = <nowiki> Re: Jumbolino </nowiki>  
   | url    = http://sourceforge.net/p/flightgear/mailman/message/34640695/
   |author = <nowiki> curt </nowiki>  
   | title  = <nowiki>[Flightgear-devel] Launcher changes for 3.8</nowiki>
   |date  = Sep 2nd, 2016
   | author = <nowiki>James Turner</nowiki>
  |added  =  Sep 2nd, 2016
   | date  = Nov 23rd, 2015
   |script_version = 0.40
   }}
  }}</ref>
}}


== Initial Prototype ==
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. <ref>{{cite web
{{Note|
   |url    = https://forum.flightgear.org/viewtopic.php?p=287894#p287894
{{FGCquote
   |title  = <nowiki> Re: A call for FlightGear wiki logos for the 3rd party hanga </nowiki>  
  |The replacement launcher is very young, so I apologise for any functionality gaps. '''In general it emphasises setting only the things that cannot be changed at runtime, and some common general settings''' (real weather, time of day, location). That’s why anti-aliasing and Rembrant are exposed but not multi-player settings, since the in-sim UI works perfectly for those features. The same is true for scenarios and AI traffic.
   |author = <nowiki> curt </nowiki>  
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33464757/
   |date  = Jun 6th, 2016  
    |title=<nowiki>Re: [Flightgear-devel] Release 3.4.0 is coming</nowiki>
   |added = Jun 6th, 2016  
    |author=<nowiki>James Turner</nowiki>
   |script_version = 0.40
    |date=<nowiki>2015-02-19</nowiki>
   }}</ref>
  }}
}}
{{FGCquote
|1= Having many fewer options than FGRun is deliberate and intentional - the idea is to give control over:
* very commonly used options by most users  
* options that can’t be changed once the simulator is running
This is why for example there’s no control over view settings or multiplayer. (But real-weather and time-of-day are included even though they can be changed in-sim, because I judged them to be common)
|2= {{cite web
   | url    = http://sourceforge.net/p/flightgear/mailman/message/34752731/
   | title  = <nowiki>Re: [Flightgear-devel] Issues with Qt5 launcher</nowiki>
   | author = <nowiki>James Turner</nowiki>
   | date  = Jan 9th, 2016
   | added   = Jan 9th, 2016
   | script_version = 0.23
   }}
}}
}}
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 and before the FlightGear main loop is running, this will be merged for 3.4, hopefully with no impact on other platforms.


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)<ref>http://forum.flightgear.org/viewtopic.php?p=234090#p234090</ref>.


The qt launcher is not intended for use on non-OSX platforms in 3.4. It's being generalised to work on all platforms on 'next' for 3.6, but it should be ignored by anyone except me in 3.4. (Eg, there is language on the buttons which is OS-X specific, references to 'the Finder')<ref>http://sourceforge.net/p/flightgear/codetickets/1709/#b545</ref>
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.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=293854#p293854
  |title  =  <nowiki> Re: How the project works </nowiki>
  |author =  <nowiki> curt </nowiki>
  |date  =  Sep 7th, 2016
  |added  =  Sep 7th, 2016
  |script_version = 0.40
  }}</ref>


Some code James has written in the 2014 will be obsolete, e.g. the native message box and menubar code.
{{Main article|QtQuick use in FlightGear}}
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.<ref>{{cite web
|url=https://forum.flightgear.org/viewtopic.php?f=18&t=25115#p229445
|title=Re: New Canvas GUI
|author=Torsten
|date=Jan 10th, 2015
}}</ref> This will result in the following user interface:
* Qt launcher
* Internal UI based possibly with Qt/[[Canvas]] integration
* External browser-based UI (Phi)


== User Interface ==
However, it should be made clear that Qt will always remain an optional dependency.<ref name="GUIquestions">{{cite web
{{FGCquote
|url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
|1= I am fairly firm that I /don’t/ want to add many more options, at least before doing a much more serious UI redesign. To explain. the current UI aims to give you control over things you can’t change inside the sim, and also expose very commonly used settings. Keeping the UI clean and uncluttered is a much higher priority than exposing every command line option and feature of the internal GUIs. The longer term solution here is to switch from the current horiontal tabs to a different layout which can support more pages (probably a vertical tab-set with icons), and to put complex options into pages which are hidden by default, and which users can progressively enable. Multiplayer and failures would be possible examples of this.
|title  = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
|2= {{cite web
|author = James Turner
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34649467/
|date  = Oct 11th, 2015
  | title  = <nowiki>Re: [Flightgear-devel] Launcher changes for 3.8</nowiki>
}}</ref>
  | author = <nowiki>James Turner</nowiki>
  | date  = Nov 26th, 2015
  }}
}}


== Preferences ==
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.<ref>{{cite web
{{FGCquote
   |url    = https://sourceforge.net/p/flightgear/mailman/message/35863607/  
|1= The preferences file for the launcher is stored in the default location for Qt - which means ~/Library/Preferences on Mac, and the registry on Windows, and whatever XDG/FreeDesktop defines on Linux. You can reset all the FlightGear settings by holding down ‘alt’ on starting the launcher - this also resets any FlightGear saved settings (autosave). Unfortunately pressing alt at the right time is tricky, I’d welcome other suggestions for this.
   |title  = <nowiki> Re: [Flightgear-devel] KBOS runway list? are there 10 or are there
|2= {{cite web
12? </nowiki>  
   | url    = http://sourceforge.net/p/flightgear/mailman/message/34642397/
   |author = <nowiki> James Turner </nowiki>  
   | title  = <nowiki>Re: [Flightgear-devel] Qt launcher and phi-utility FGFS 3.6.0 RC
   |date  = May 28th, 2017
to 3.7.0</nowiki>
   |added = May 28th, 2017
   | author = <nowiki>James Turner</nowiki>
   |script_version = 0.40
   | date  = Nov 23rd, 2015
   }}</ref>
   | added   = Nov 23rd, 2015
   | script_version = 0.23
   }}
}}


== Repercussions ==
=== Dependencies ===
=== Aircraft Center ===
There is 100% agreement that FlightGear will never require Qt<ref>{{cite web
{{FGCquote
   |url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
|1= James's new aircraft center looks at his own path on his own web site for aircraft .ip packages (not the previously usual ftp tree.) He created his own scripts to generate the .zip files and named the packages slightly differently from how it was done previously.
   |title  = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
|2= {{cite web
   |author = <nowiki>James Turner</nowiki>
   | url    = http://sourceforge.net/p/flightgear/mailman/message/34868519/
   |date  = Oct 11th, 2015
   | title  = <nowiki>Re: [Flightgear-devel] Announcing the Release of FlightGear 2016.1.1</nowiki>
   |added = May 7th, 2016
   | author = <nowiki>Curtis Olson</nowiki>
   |script_version = 0.35
   | date  = Feb 20th, 2016
   | added   = Feb 20th, 2016
   | script_version = 0.25
   }}
   }}
}}
</ref>, 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.<ref>{{cite web
=== Qt5 remaining optional ===
   |url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
{{FGCquote
   |title  = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
|1= My personal take is that most normal users /will/ use the Qt-UI build because it will offer the easiest and most integrated GUI experience
   |author = <nowiki>James Turner</nowiki>
|2= {{cite web
   |date  = Oct 11th, 2015
   | url    = http://sourceforge.net/p/flightgear/mailman/message/34537052/
   |added = May 7th, 2016
   | title  = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki>
   |script_version = 0.35
   | author = <nowiki>James Turner</nowiki>
   | date  = Oct 13th, 2015
   | added   = Oct 13th, 2015
   | script_version = 0.23
   }}
   }}
}}
</ref>
=== 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<ref name="a">http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>.


=== Dependencies ===
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. <ref>{{cite web
{{FGCquote
  |url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
   |There's been a strong devision of opinion among a couple of core developers with respect to the question whether a QT dependency is desirable or not. In one of the [[Weekly Developer Hangout|hangouts]], a couple of months ago, we had the chance to discuss the pros and cons, when the most outspoken developers regarding this issue were both present. We concluded that a QT dependency was undesirable, unless it had a specific benefit. With this in mind, I proposed to consider the option of allowing a QT dependency in only one module (call it FGGui). For all practical purposes, this would be a platform independent replacement of fgrun, but because of the proposed modularity, it will appear to be seamlessly integrated with FlightGear. Both developers representing the opposite ends of the debate could live with this compromise.
  |title  = <nowiki>[Flightgear-devel]  GUI questions (again)</nowiki>
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34196458/
  |author = <nowiki>James Turner</nowiki>
    |title=<nowiki>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki>
  |date  = Oct 11th, 2015
    |author=<nowiki>Durk Talsma</nowiki>
  |added  = May 7th, 2016
    |date=<nowiki>2015-06-11</nowiki>
   |script_version = 0.35
  }}
  }}
}}
</ref>
For the time being, Qt is only needed for the launcher feature, which is automatically disabled if it is not found<ref>http://sourceforge.net/p/flightgear/mailman/message/33498614/</ref>.
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.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34196458/
If CMake does not find QT5 then it skips the QT launcher compilation<ref>http://sourceforge.net/p/flightgear/mailman/message/33498869/</ref>. Thus, Qt5 is an optional build dependency and people can continue to use other other front-ends (fgrun, fgx etc).
|title=<nowiki>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki>
 
|author=<nowiki>Durk Talsma</nowiki>
On systems without Qt5 support, you will see this:
|date=<nowiki>2015-06-11</nowiki>
}}</ref> 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.


If CMake is not able to find Qt 5.1 (the minimum required version) or later, the launcher is not compiled,<ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498614/
|title  = <nowiki>Re: [Flightgear-devel] FGData splitting / assembling the base
package</nowiki>
|author = Rebecca N. Palmer
|date  = Feb 26th, 2015
}}</ref><ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498869/
|title  = <nowiki>Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear
git</nowiki>
|author = Bertrand Coconnier
|date  = Feb 26th, 2015
}}</ref> and the following message will be printed:
<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
-- Qt launcher enabled, checking for Qt 5.1 / qmake
-- Qt launcher enabled, checking for Qt 5.1 / qmake
Line 208: Line 209:
   to a directory containing one of the above files.  If "Qt5" provides a
   to a directory containing one of the above files.  If "Qt5" provides a
   separate development package or SDK, be sure it has been installed.
   separate development package or SDK, be sure it has been installed.
</syntaxhighlight>
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).
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<ref>http://forum.flightgear.org/viewtopic.php?p=229563#p229563</ref>
=== Segfaults & Race Conditions ===
{{Note|Also see {{Issue|1819}}}}
{{FGCquote|1= 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?|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34430800/  | title  = <nowiki>Re: [Flightgear-devel] fgaddon c310 typos??</nowiki>  | author = <nowiki>Ray St. Marie</nowiki>  | date  = Sep 3rd, 2015  }}}}
{{FGCquote|1= The problem with GUI coding is that it is very, very hard - it is much more problematic than normal coding and causes far more headaches (from all the banging of your head against the wall trying to work out why it is racing and segfaulting on one system and not another). |2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34430850/  | title  = <nowiki>Re: [Flightgear-devel] fgaddon c310 typos??</nowiki>  | author = <nowiki>Edward d'Auvergne</nowiki>  | date  = Sep 3rd, 2015  }}}}
{{FGCquote|1= 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.|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/34431801/  | title  = <nowiki>Re: [Flightgear-devel] Debug build / crash on exit</nowiki>  | author = <nowiki>Edward d'Auvergne</nowiki>  | date  = Sep 4th, 2015  }}}}
{{FGCquote
|1= One concern I have though, from the discussions over the last year, is that the PUI->Qt migration plan is not a direct one-to-one migration. I.e. to have a main Qt window providing the main FlightGear window by containing a top menu bar followed by a QtWindow GL widget underneath, in which the FG main execution loop is run as a thread from within the Qt main loop. My impression was that the GUI will be a secondary window or dialog that you have to switch to. But one problem I see with this design is that all modern GUI toolkits (Qt, GTK, metro, Cacoa, Carbon, etc.) suffer from racing and segfaulting issues if the GUI main thread or main loop/event handler is not thread number 1.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34536197/
  | title  = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
  | date  = Oct 13th, 2015
  }}
}}
<references/>
=== Canvas ===
{{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]]) [http://sourceforge.net/p/flightgear/mailman/message/34196458/].
}}
{{FGCquote
|1= Canvas works fine in this scenario, we can embed the texture or image a Canvas produces into a QtQuick dialog just fine. (It would be possible to reimplement Canvas using Qt but I don’t see any benefit there - the non-Qt builds still need Canvas support for flight-displays and the like)
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34532040/
  | title  = <nowiki>[Flightgear-devel]  GUI questions (again)</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Oct 11th, 2015
  | added  = Oct 11th, 2015
  | script_version = 0.23
  }}
}}
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)<ref name="a">http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>. 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).
The latter is an increasingly important use-case in real life avionics (on jets/airliners) - as can be seen by  [[ARINC 661]]. Such use-cases aren't easily supported by a distributed approach involving for example a browser, HTML5 and ECMAScript/JavaScript
In addition, the idea is to keep modernizing and [[Unifying_the_2D_rendering_backend_via_canvas|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: <ref>http://forum.flightgear.org/viewtopic.php?p=229311#p229311</ref>. 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 ===
{{FGCquote
|1= While Qt5 would still be an awesome feature from a Canvas perspective, it is simply not an option as long as it is entirely optional, because at that point,  some Canvas-based MFD features would no longer work for FlightGear versions without Qt5 support included.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
  | title  = <nowiki>Re: Aircraft reselection </nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jan 10th, 2016
  }}
}}
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:
<gallery widths="400">
Qt launcher for FlightGear 3.5 on Windows 7 location.jpg|This is the location tab of the new Qt5-based launcher, which is entirely hard-coded in C++
Airport-selection-dialog.png|A [[Canvas]]/[[MapStructure]] based view of airports with runways/taxiways
</gallery>
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.
{{FGCquote
|1= The main motivation why some people want to have a Nasal/Canvas-based GUI is to ensure that aircraft avionics can make use of the GUI toolkit, but also so that the integrated GUI can deal with existing Canvas based features (think avionics).
In layman's terms, all this comes down to being able to render a MFD (PFD/ND) in a dialog box, but also to render GUI widgets to a Canvas, i.e. true recursion - as long as this use-case is supported, it does not matter whether Qt5 is used for this or not, the only thing that matters is that it would be possible to create an integrated GUI for editing/maintaining MFD avionics, but also other Canvas-feature (think having a built-in HUD or 2D panels editor).
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=272314#p272314
  | title  = <nowiki>Re: Aircraft reselection </nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jan 10th, 2016
  }}
}}
Once the [[Canvas Development#The_Future_of_Canvas_in_FlightGear|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) ===
{{Main article|Howto:Processing legacy PUI dialogs using Canvas}}
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<ref>http://forum.flightgear.org/viewtopic.php?p=229563#p229563</ref>.
However, the goal is to make an '''optional''' Qt dependency to replace PLIB PUI<ref>http://sourceforge.net/blog/november-2015-community-choice-project-of-the-month-flightgear/</ref>.
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<ref>http://sourceforge.net/p/flightgear/mailman/message/34532040/</ref>.
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<ref name="a">http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>.
{{FGCquote
|1= From what I've seen, I don't see any reason why there cannot be a direct one-to-one migration of the PUI GUI main window to a Qt main window, including dynamically generating the aircraft menu and submenus by parsing the XML unmodified. This can be done incrementally as it is developed, and probably in a way that requiresero changes to the aircraft PUI GUI XML (though changes could be made later, as you can do far, far more with Qt than with PUI). So I personally think that targeting dialogs for the PUI GUI would be the best way to go as this can be directly translated by the GUI developers into Qt dialogs requiring the aircraft developers to do nothing
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34536197/
  | title  = <nowiki>Re: [Flightgear-devel] GUI questions (again)</nowiki>
  | author = <nowiki>Edward d'Auvergne</nowiki>
  | date  = Oct 13th, 2015
  }}
}}
{{FGCquote
|1= 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_Widgets
For 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
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=272148#p272148
  | title  = <nowiki>Re: Can't install FGRun package (+ rant about Qt5 launcher)</nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Jan 9th, 2016
  | added  = Jan 9th, 2016
  | script_version = 0.23
  }}
}}
{{FGCquote
|1= I am strongly against using a very non-standard UI (a text box + slider) to achieve that interaction. I’d much rather we add a spin-box to PUI, which is not especially hard, and give it the ‘click and drag’ mouse interaction which some spinboxes in other apps have, to give similar UI to the sliders without the visual clutter.
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34747786/
  | title  = <nowiki>Re: [Flightgear-devel] Speed-up vs time-warp</nowiki>
  | author = <nowiki>James Turner</nowiki>
  | date  = Jan 7th, 2016
  | added  = Jan 7th, 2016
  | script_version = 0.23
  }}
}}
<references/>
=== FGRun ===
The upcoming FlightGear 3.6 release is likely to contain an integrated, hard-coded, launcher based on Qt5 to work around the issue of the mac launcher no longer working on Yosemite<ref>http://forum.flightgear.org/viewtopic.php?p=228961#p228961</ref>, because James Turner is prototyping a Qt5 cross-platform GUI <ref>http://forum.flightgear.org/viewtopic.php?p=232593#p232593</ref>.
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.<ref>http://sourceforge.net/p/flightgear/codetickets/1591/#4cb7</ref>.
{{DeQuote}}
{{FGCquote
  |Gijs was the one who took over fgrun maintenance, and he stated quite clearly that he believes in phasing out fgrun and favoring the new Qt5 based launcher instead
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=240118#p240118
    |title=<nowiki>Re: Multiple aircraft versions not allowed in FGRun.  </nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Thu Apr 23</nowiki>
  }}
}}
{{FGCquote
  |FGRun will be replaced by the built-in launcher in the next weeks, this is a known long term goal that's why FGRun haven't been improved the last 6 months and he won't be improved anymore. By using FGRun you won't be able to use all the new features in the future.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235136#p235136
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>F-JJTH</nowiki>
    |date=<nowiki>Sat Mar 14</nowiki>
  }}
}}
{{FGCquote
  |it isn't just a rewrite from scratch... it is built into fgfs... not a separate executable... i suspect that when it is completed, "--launcher" will be removed and it will be the first thing you see when starting fgfs but i could be wrong about that
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235178#p235178
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>wkitty42</nowiki>
    |date=<nowiki>Sat Mar 14</nowiki>
  }}
}}
{{FGCquote
  |fgfs has to at least be built with Qt5... on my linux system, i don't recall any Qt5 stuff being installed when i first pulled fgfs 3.4.0 from the PPA where they (sorry, i don't recall his name as i'm still very new and learning everyone) had built 3.4.0 and then 3.4.1 with Qt5... when i started using the download_and_compile script, Qt5 was not installed on my machine so the --launcher option didnt work with my self-compiled 3.5.0... then some updates were made and i got a new copy of the script because of the fgdata split and that did install some Qt5 stuff on my box... i'm guessing that the installers will take care of what needs to be
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235217#p235217
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>wkitty42</nowiki>
    |date=<nowiki>Sun Mar 15</nowiki>
  }}
}}
{{FGCquote
  |3.4 will need, if you have system-side QT5 libraries, namely the qtbase5-dev package on Ubuntu that provides these QT libraries.<br/>
<br/>
i still think FGRUN is ment to stay,,,<br/>
<br/>
edit: at least if you compile stable FG from the brisa's download_and_compile script, you'll need QT, but it might still error compile even if your compiling by hand... but there's an QT conditional commit on Sourceforge's "next" for those without QT, but i'm not sure if it's merged yet into release/3.4
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235630#p235630
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>hamzaalloush</nowiki>
    |date=<nowiki>Tue Mar 17</nowiki>
  }}
}}
{{FGCquote
  |grun is a separate tool, so can obviously be used just as well - and it is very likely that it will be much more complete than the Qt based launcher for at least 2-3 release cycles, which also applies to other polished front-ends, like for example FGx.<br/>
<br/>
However, the mid-term idea is to phase out external launchers and provide built-in means to start up and configure FG using a simple UI.<br/>
Also, for the last few years, Gijs  has basically been maintaining fgrun - and here's what he had to say about the future of fgrun in fgfs: [http://sourceforge.net/p/flightgear/codetickets/1529/#cd07 http://sourceforge.net/p/flightgear/cod ... 1529/#cd07]
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235634#p235634
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Mar 17</nowiki>
  }}
}}
{{FGCquote
  |The other issue here being that the Qt launcher in its current form is implemented in a way that makes it only useful during startup, i.e. the current implementation basically kills the UI once the simulator has initialized. So it's not just a certain disparity features-wise, but the UI also won't be available at run-time, which may take another 1-2 release cycles to address.<br/>
<br/>
Obviously, people can continue to use external launchers like fgrun/fgx still - but there are pretty strong advantages once a built-in launcher is properly integrated - so if/when, the Qt5-based UI will evolve, it is likely that external launchers will generally become obsolete for most purposes/end-users - which isn't such a bad thing actually, given the crazy number of FG GUI front-ends we have seen over the years.<br/>
<br/>
Keep in mind that an external launcher like fgrun will also eat up resources while FG is running - while an integrated solution could be much more efficient.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235634#p235634
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Mar 17</nowiki>
  }}
}}
{{FGCquote
  |i applaud this effort by Gijs, but i still think users should be able to use external tools as well, as you have confirmed now thankfully.<br/>
<br/>
since QT is bieng agreed upon to be the launcher for FG accross platforms, does this mean it will merge into FG as well?? i think Canvas is much better for menu since we are using built-in framework.<br/>
<br/>
not to mention other QT dependance and maintanance issues.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235635#p235635
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>hamzaalloush</nowiki>
    |date=<nowiki>Tue Mar 17</nowiki>
  }}
}}
{{FGCquote
  | the whole step is long overdue - and for FG it is a huge improvement. FlightGear has become a fairly sizable code base, with tons of legacy code, while making very little use of modern frameworks/libraries. Accepting Qt5 as a general dependency would be a huge shift in thinking, and it could help improve/modernize the FG architecture significantly.<br/>
However, it's a tedious process, too - i.e. updating all the legacy code accordingly and getting rid of old cruft in the process.<br/>
And so far, there's only a single core developer pursuing this. And looking back in time, we've seen similar efforts that ultimately turned out to be too tedious to be accepted by the wider communtiy of contributors, so that such efforts would ultimately turn out to be merely "experiments" - and "iterations" of a process to arrive at a completely different solution.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235646#p235646
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Mar 17</nowiki>
  }}
}}
{{FGCquote
  |having started without any kind of launcher and then finding FGRun and now having played with the Qt5 launcher, i do hope that all the capabilities of FGRun are incorporated into the new one... i'm always getting bitten in the arse when i forget to specify something on the command line with the "--launcher" option... "--http{{=}}5500" being one of those... there are others... FGRun saves the last used options so the next time they are already set...
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235167#p235167
    |title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>wkitty42</nowiki>
    |date=<nowiki>Sat Mar 14</nowiki>
  }}
}}
<references/>
=== Python in FlightGear ===
{{See also|Python in FlightGear}}
{{See also|FGPythonSys}}
{{FGCquote
|1= depending on how much progress bugman is going to make with his "python-integration-in-FlightGear" experiments  (FGPythonSys), we may at some point even be able to ship FFGo as part of FGData (e.g. $FG_ROOT/Python/Apps/FFGo) and run it via FGPythonSys directly
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=275910#p275910
  | title  = <nowiki>Re: Announcing </nowiki>
  | author = <nowiki>Hooray</nowiki>
  | date  = Feb 12th, 2016
  | added  = Feb 12th, 2016
  | script_version = 0.25
  }}
}}
{{FGCquote
|1= if this FGPythonSys were integrated into FG, doing things in Python that are directly committed to the core (properly reviewed---well, as the C++ code) as opposed to coming from various uncontrolled external places would certainly be pretty interesting
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=275923#p275923
  | title  = <nowiki>Re: Announcing </nowiki>
  | author = <nowiki>rominet</nowiki>
  | date  = Feb 13th, 2016
  | added  = Feb 13th, 2016
  | script_version = 0.25
  }}
}}
{{FGCquote
|1= The built-in launcher that James is writing would seem to me to be a good candidate for doing things in Python (assuming there are good bindings to the C++ data structures): you need high-level access to FG aircraft and airport data, it is not performance critical, the need for threading is certainly rather limited, the code does not come from a random hangar and can be audited just like the C++ code when committed, probably by more people actually. Add to this that PyQt works very well (I have had a very pleasant experience with PyQt 3&amp;4 under Python 2&amp;3, and if I get enough time, I'll maybe port FFGo to PyQt---Tk is useful, clearly, but frustrating; for example Qt's QAbstractItemModel and QAbstractItemView were great to manage non-trivial tablular data; with Tk, table/tree cells are just strings and your program has to manage on its own to link that to the nice high-level Python data structures).
(and I have tried other toolkits before Qt and Tk, namely GTK+ 1.2 and wxWidgets [around 2003] Bottom line: for me, Qt is the best)
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=275923#p275923
  | title  = <nowiki>Re: Announcing </nowiki>
  | author = <nowiki>rominet</nowiki>
  | date  = Feb 13th, 2016
  | added  = Feb 13th, 2016
  | script_version = 0.25
  }}
}}
== Testing ==
The launcher is not run by default, this is because it was created as a Mac only solution.
You can test the launcher by passing the <code>--launcher</code> argument, or setting the <code>$FG_LAUNCHER</code> 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.
{{FGCquote
|1= If you want to use the new one, specify the following parameters in the box at the bottom of the ''Settings'' tab:
<syntaxhighlight>
--console --multiplay=out,10,mpserver01.flightgear.org, --multiplay=in,10,, --callsign=WF01 --visibility=75
</syntaxhighlight>
</syntaxhighlight>


(replace the name of the multiplayer server, the callsign and the visibility - in meters - as appropriate).
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.
|2= {{cite web
  | url    = http://forum.flightgear.org/viewtopic.php?p=276569#p276569
  | title  = <nowiki>Re: FG 2016,1.1</nowiki>
  | author = <nowiki>elgaton</nowiki>
  | date  = Feb 18th, 2016
  | added  = Feb 18th, 2016
  | script_version = 0.25
  }}
}}
 
The GUI launcher included in the [[FlightGear Build Server|nightly builds]] includes a new dialog to set up (and remember) [[$FG_ROOT]] using a file picker dialog. It does some version checking to hopefully make things as robust as possible for the user<ref>http://sourceforge.net/p/flightgear/mailman/message/33646906/</ref>.
 
And if you run fgfs via the command line with some options, you don’t get troubled by the launcher.
 
{{note|If you need the <code>--console</code> switch, it doesn't appear to work in the launcher command line args area. In Windows however you can add it behind the <code>--launcher</code> switch in the shortcut "Target" path.}}
 
== Community Feedback ==
{{FGCquote
|1= My issues are:
* I really would like to be able to see ONLY the planes I have installed on my system and not every single plane available for FG. Maybe a checkbox "show only local planes" could solve this? * I can't use a different FGDATA path, which was a very handy feature of FGRun. Even adding <nowiki>--fg-root=/path/to/fgdata</nowiki> to the "Additional options" field doesn't work. - when trying to add Aircraft and Scenery paths, I am presented with a dialog to find them, but I can't see hidden folders there, and Ctrl+H doesn't affect it  
* I can't seem to be able to move a scenery path up and down to change the priority order, which is fundamental when using custom scenery
* seems to have much fewer options than FGRun, some of which were handy (for instance, where can I set texture compression now?)
* I love the airport view but I would expect I could position and rotate my aircraft anywhere by clicking around instead of being able to only select runways (which would be a handy feature to start at a parking position if it's not defined for a given airport)
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34752316/
  | title  = <nowiki>[Flightgear-devel] Issues with Qt5 launcher</nowiki>
  | author = <nowiki>Gilberto Agostinho</nowiki>
  | date  = Jan 9th, 2016
  | added  = Jan 9th, 2016
  | script_version = 0.23
  }}
}}
 
== Cross-Compiling using MingW64 ==
{{Main article|Building FlightGear - Cross Compiling}}
{{FGCquote
  |they [mxe] still have QT &lt; 5.1, so that's an issue that we will have to resolve at a later date for our new GUI, for now, i will be contempt with cross-compilling FG 3.4 when i'm done just as a proof-of-concept.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
    |title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
    |author=<nowiki>hamzaalloush</nowiki>
    |date=<nowiki>Thu May 14</nowiki>
  }}
}}
 
== Development ==
Note the launcher on '''next''' will be in flux shortly as James will add some new features - support for the [[FlightGear Package Manager|aircraft package manager]] especially, and for specifying some directory locations to support "code only" nightly builds (see [[FlightGear Build Server]]) which use an existing FGData download<ref>http://sourceforge.net/p/flightgear/mailman/message/33503142/</ref>.
 
{{FGCquote
  |This [add-on] screen is work-in-progress, I have moved it already in my local version, but didn’t push the changes yet. There’s new UI around the download location too, and the aircraft-dir changes you mention. For aircraft package support in general, I am hoping that setting FG_AIRCRAFT / —fg-aircraft might not be needed, i.e if aircraft-dir is explicitly set, that would be sufficient. This makes having multiple variants of aircraft co-installed much easier for the package system, but will likely need some code fixes as you already identified.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33683510/
    |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-03-31</nowiki>
  }}
}}
 
{{FGCquote
  |this is an area I’m actively working on, especially how FG to aircraft version handling in the package system works. My current focus is to generate some test hangars on web-hosts to test against, once that works I will call out for other volunteers (Syd Adams already gracefully offered). Expect some churn in this area, in the next few weeks.
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33683532/
    |title=<nowiki>Re: [Flightgear-devel] Non-existent default catalog</nowiki>
    |author=<nowiki>James Turner</nowiki>
    |date=<nowiki>2015-03-31</nowiki>
  }}
}}


{{FGCquote|1= 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).|2= {{cite web | url    = http://sourceforge.net/p/flightgear/mailman/message/34560946/  | title  = <nowiki>Re: [Flightgear-devel] FGFS Launcher -->selecting Parkpositions ???</nowiki> | author = <nowiki>Edward d'Auvergne</nowiki>  | date  = Oct 22nd, 2015 }}}}
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.<ref name="GUIhell">{{cite web
|url    = http://forum.flightgear.org/viewtopic.php?p=229563#p229563
|title  = <nowiki>Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??</nowiki>
|author = Torsten
|date  = Jan 11th, 2015
}}</ref>


== Issues ==
== Related content ==
 
* [[FlightGear Qt launcher wish list]]
* [http://forum.flightgear.org/viewtopic.php?f=22&t=26504#p246868 Airplane is in FG root, can't see in flightgear wizard]  ·{{Issue|#1772}}
 
{{FGCquote
  |The default aircraft catalog download path is http://fgfs.goneabitbursar.com/pkg/<version>/default-catalog.xml, which does not exist for 3.4.0 or 3.5.0, giving a "catalog download failure:" error and an empty Aircraft Center [{{Issue|1737}}].
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33679386/
    |title=<nowiki>[Flightgear-devel] Non-existent default catalog</nowiki>
    |author=<nowiki>Rebecca N. Palmer</nowiki>
    |date=<nowiki>2015-03-31</nowiki>
  }}
}}
 
{{FGCquote
  |The "Add-ons" tab of the launcher has several problems on Linux [see posting for details]
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33679374/
    |title=<nowiki>[Flightgear-devel] Launcher issues on Linux</nowiki>
    |author=<nowiki>Rebecca N. Palmer</nowiki>
    |date=<nowiki>2015-03-31</nowiki>
  }}
}}
 
{{FGCquote
  |Further investigation found that the launcher *is* trying to add this directory to fg-aircraft (src/GUI/QtLauncher.cxx:772), but that this doesn't work because this option is processed before the launcher is run (intentionally, to allow the launcher to find aircraft in fg-aircraft: src/Main/main.cxx:448).
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33686356/
    |title=<nowiki>Re: [Flightgear-devel] Launcher issues on Linux</nowiki>
    |author=<nowiki>Rebecca N. Palmer</nowiki>
    |date=<nowiki>2015-04-01</nowiki>
  }}
}}


{{Appendix}}
{{Appendix}}


[[Category:Core development projects]]
[[Category:Core development projects]]
[[Category:FlightGear front ends]]

Revision as of 14:20, 10 April 2019

FlightGear Qt launcher
The aircraft page of the Qt launcher for FlightGear 2018.2 as rendered on Windows 10
The aircraft page of the Qt launcher for FlightGear 2018.2 as rendered on Windows 10
Started in 01/2015
Description Integrated launcher for FlightGear
Maintainer(s) James Turner
Contributor(s) James Turner
Status Under active development
Folders flightgear/flightgear/next/src/GUI
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).

Usage

To run the launcher:

  • Microsoft Windows: double-click the FlightGear <version> icon on the Desktop or click on Start > All Programs > FlightGear <version> > FlightGear Launcher.
  • OS X and Linux: open a terminal and run fgfs with the option --launcher:
    $ fgfs --launcher
    

Note that 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.

Installing Scenery

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.[1]

Preferences

In FlightGear 2016.2 and later, the preferences are stored in $FG_HOME/flightgear.org/FlightGear.ini.[1] Older versions make use of the default location used by Qt:

  • 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.[2]

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 RubyCocoa This is a link to a Wikipedia article, 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.[3]

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.[4]

As of version 2016.4, FGRun has been removed from the official distributions.

Background

Cleanup.png This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.

In addition, this was also motivated by the plethora of 3rd party GUI launchers/frontends developed by numerous contributors over the years [5].

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.[6]


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.)[7]

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. [8]


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.[9]

1rightarrow.png 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.[10] 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.[11]

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.[12]

Dependencies

There is 100% agreement that FlightGear will never require Qt[13], 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.[14]

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. [15] 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.[16] 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.

If CMake is not able to find Qt 5.1 (the minimum required version) or later, the launcher is not compiled,[17][18] and the following message will be printed:

-- 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.[19]

Related content

References
  1. 1.0 1.1 James Turner (Apr 8th, 2016). [Flightgear-devel] Launcher add-on handling changes.
  2. James Turner (Nov 23rd, 2015). Re: [Flightgear-devel] Qt launcher and phi-utility FGFS 3.6.0 RC to 3.7.0.
  3. https://sourceforge.net/p/flightgear/fgdata/ci/654a343bbb7eb51b387060515e3415e152d12c2a/
  4. https://sourceforge.net/p/flightgear/mailman/message/35689137/
  5. The FlightGear Front-End Situation
  6. Thorsten  (Jul 26th, 2016).  Re: 2016.x.x take off from carrier .
  7. curt  (Sep 2nd, 2016).  Re: Jumbolino .
  8. curt  (Jun 6th, 2016).  Re: A call for FlightGear wiki logos for the 3rd party hanga .
  9. curt  (Sep 7th, 2016).  Re: How the project works .
  10. Torsten (Jan 10th, 2015). Re: New Canvas GUI.
  11. James Turner (Oct 11th, 2015). [Flightgear-devel] GUI questions (again).
  12. James Turner  (May 28th, 2017).  Re: [Flightgear-devel] KBOS runway list? are there 10 or are there 12? .
  13. James Turner (Oct 11th, 2015). [Flightgear-devel] GUI questions (again).
  14. James Turner (Oct 11th, 2015). [Flightgear-devel] GUI questions (again).
  15. James Turner (Oct 11th, 2015). [Flightgear-devel] GUI questions (again).
  16. Durk Talsma (2015-06-11). Re: [Flightgear-devel] Policy Document and V4.X Roadmap.
  17. Rebecca N. Palmer (Feb 26th, 2015). Re: [Flightgear-devel] FGData splitting / assembling the base package.
  18. Bertrand Coconnier (Feb 26th, 2015). Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear git.
  19. Torsten (Jan 11th, 2015). Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??.