FlightGear Qt launcher: Difference between revisions

Jump to navigation Jump to search
Partial dequote, style fixes
(More ref expansion)
(Partial dequote, style fixes)
Line 9: Line 9:
| maintainers    = {{usr|Zakalawe|James Turner}}
| maintainers    = {{usr|Zakalawe|James Turner}}
| developers    = James Turner
| developers    = James Turner
| status        = Under active development as of 03/2016.
| status        = Under active development as of 05/2016.
| folders        = {{flightgear source|path=src/GUI}}
| folders        = {{flightgear source|path=src/GUI}}
| changelog      = {{flightgear source|path=src/GUI|view=log}}
| changelog      = {{flightgear source|path=src/GUI|view=log}}
Line 18: Line 18:
{{Package Management}}
{{Package Management}}


== History ==
== 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 the FlightGear Mac launcher incompatible with OS X Yosemite. James Turner started work on a solution for the then-upcoming FlightGear v3.4 release. He added a simple launcher using Qt to the main process, run before the OSG window would be created. It was released with FG 3.4 as a Mac-only feature.
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 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 FlightGear Graphical User Interface. In FlightGear v3.6, it became available for all platforms, and has continued to be developed, enhanced, and refined.
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.


== Usage ==
== Usage ==
Unlike [[FGRun]], which has its own executable (<tt>''fgrun.exe''</tt>), the Qt launcher must be run by executing <tt>''fgfs.exe''</tt> with the option <code>--launcher</code>:
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 <tt>fgfs</tt> with the option <code>--launcher</code>:
<syntaxhighlight lang="shell">
<syntaxhighlight lang="shell">
$ fgfs --launcher
$ fgfs --launcher
</syntaxhighlight>
</syntaxhighlight>
{{note|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.}}


<gallery mode="packed">
<gallery mode="packed">
Line 34: Line 40:
Qt launcher for FlightGear 3.5 on Windows 7 addons.jpg|Addons page of Qt launcher in FG 3.5 on Windows 7
Qt launcher for FlightGear 3.5 on Windows 7 addons.jpg|Addons page of Qt launcher in FG 3.5 on Windows 7
</gallery>
</gallery>
=== Multiplayer connections ===
As the launcher is still under development, only some basic options are present; notably, no multiplayer option is shown. To connect to the multiplayer servers, either:
* start FlightGear from the launcher and then choose '''Multiplayer''' -> '''Multiplayer Settings''' inside the simulator;
* or open the '''Settings''' tab in the launcher and specify the following parameters:
<syntaxhighlight lang="shell">
--console --multiplay=out,10,mpserver01.flightgear.org, --multiplay=in,10,, --callsign=mycallsign
</syntaxhighlight>
replacing ''mpserver01.flightgear.org'' with the multiplayer server to be used and ''mycallsign'' with the desired callsign.
=== Enabling console display on Windows systems ===
To enable console display on Windows systems, right-click on the FlightGear shortcut on the Desktop and click '''Properties'''. In the '''Target''' box, add <tt>--launcher</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>


== Background ==
== Background ==
In accordance with the [[FlightGear 4.xx Roadmap]], FlightGear's current GUI interface, based on the [[PUI]] library of [[PLIB]], will be replaced by one based on Qt. [[FGRun]] will also be removed in future to be replaced by this launcher. In addition, a browser-based UI (called [[Phi]]) will continue to be developed in parallel.<ref>{{cite web
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. [[FGRun]] will also be removed in future to be replaced by this launcher. 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
|url=https://forum.flightgear.org/viewtopic.php?f=18&t=25115#p229445
|title=Re: New Canvas GUI
|title=Re: New Canvas GUI
Line 46: Line 74:
* External browser-based UI (Phi)
* External browser-based UI (Phi)


However, it should be made clear the Qt will always remain an optional dependency.<ref name="GUIquestions">{{cite web
However, it should be made clear that Qt will always remain an optional dependency.<ref name="GUIquestions">{{cite web
|url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
|url    = https://sourceforge.net/p/flightgear/mailman/message/34532040/
|title  = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
|title  = <nowiki>[Flightgear-devel] GUI questions (again)</nowiki>
Line 53: Line 81:
}}</ref>
}}</ref>


== Status ==
== Preferences ==
As of April 2016, the Qt launcher is under active development. This includes the adding of new features, fixing bugs, and refining existing features.
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 ==
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
{{FGCquote
| url    = http://sourceforge.net/p/flightgear/mailman/message/34642397/
|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] Qt launcher and phi-utility FGFS 3.6.0 RC
|2= {{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>
to 3.7.0</nowiki>
  | author = <nowiki>James Turner</nowiki>
| author = <nowiki>James Turner</nowiki>
  | date  = Nov 23rd, 2015
| date  = Nov 23rd, 2015
  | added  = Nov 23rd, 2015
| added  = Nov 23rd, 2015
  | script_version = 0.23
| script_version = 0.23
  }}
}}</ref>
}}


== Repercussions ==
== Repercussions ==
=== Dependencies ===
=== Dependencies ===
{{FGCquote
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/
  |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>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki>
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34196458/
|author=<nowiki>Durk Talsma</nowiki>
    |title=<nowiki>Re: [Flightgear-devel] Policy Document and V4.X Roadmap</nowiki>
|date=<nowiki>2015-06-11</nowiki>
    |author=<nowiki>Durk Talsma</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.
    |date=<nowiki>2015-06-11</nowiki>
 
  }}
If CMake is not able to find Qt 5.1 (the minimum required version) or later, the launcher is not compiled,<ref>{{cite web
}}
For the time being, Qt is only needed for the launcher feature, which is automatically disabled if it is not found<ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498614/
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498614/
|title  = <nowiki>Re: [Flightgear-devel] FGData splitting / assembling the base
|title  = <nowiki>Re: [Flightgear-devel] FGData splitting / assembling the base
Line 86: Line 111:
|author = Rebecca N. Palmer
|author = Rebecca N. Palmer
|date  = Feb 26th, 2015
|date  = Feb 26th, 2015
}}</ref>.
}}</ref><ref>{{cite web
If CMake does not find QT5 then it skips the QT launcher compilation<ref>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498869/
|url    = http://sourceforge.net/p/flightgear/mailman/message/33498869/
|title  = <nowiki>Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear
|title  = <nowiki>Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear
Line 93: Line 117:
|author = Bertrand Coconnier
|author = Bertrand Coconnier
|date  = Feb 26th, 2015
|date  = Feb 26th, 2015
}}</ref>. Thus, Qt5 is an optional build dependency and people can continue to use other other front-ends (fgrun, fgx etc).
}}</ref> and the following message will be printed:
 
On systems without Qt5 support, you will see this:
 
<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 115: Line 136:
</syntaxhighlight>
</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).
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<ref name="GUIhell">{{cite web
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
|url    = http://forum.flightgear.org/viewtopic.php?p=229563#p229563
|title  = <nowiki>Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??</nowiki>
|title  = <nowiki>Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??</nowiki>
Line 124: Line 145:
}}</ref>
}}</ref>


=== Segfaults & race conditions ===
=== Segmentation faults and race conditions ===
{{Note|Also see {{Issue|1819}}}}
{{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= 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  }}}}
Line 158: Line 179:
}}
}}


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="GUItech">{{cite web
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="GUItech">{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33245028/
|url    = http://sourceforge.net/p/flightgear/mailman/message/33245028/
|title  = <nowiki>[Flightgear-devel] Gui technologies</nowiki>
|title  = <nowiki>[Flightgear-devel] Gui technologies</nowiki>
|author = James Turner
|author = James Turner
|date  = Jan 20th, 2015
|date  = Jan 20th, 2015
}}</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.
}}</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).  
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
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>{{cite web
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>{{cite web
|url    = http://forum.flightgear.org/viewtopic.php?p=229311#p229311
|url    = http://forum.flightgear.org/viewtopic.php?p=229311#p229311
|title  = <nowiki>Re: New Canvas GUI</nowiki>
|title  = <nowiki>Re: New Canvas GUI</nowiki>
|author = Hooray
|author = Hooray
|date  = Jan 8th, 2015
|date  = Jan 8th, 2015
}}</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.
}}</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 ===
=== Duplicating existing functionality ===
Line 212: Line 233:
=== PLIB/PUI (legacy GUI) ===
=== PLIB/PUI (legacy GUI) ===
{{Main article|Howto:Processing legacy PUI dialogs using Canvas}}
{{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 name="GUIhell"/>.
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 name="GUIhell"/>


However, the goal is to make an '''optional''' Qt dependency to replace PLIB PUI<ref>{{cite web
However, the goal is to make an '''optional''' Qt dependency to replace PLIB PUI.<ref>{{cite web
|url    = http://sourceforge.net/blog/november-2015-community-choice-project-of-the-month-flightgear/
|url    = http://sourceforge.net/blog/november-2015-community-choice-project-of-the-month-flightgear/
|title  = November 2015, "Community Choice" Project of the Month – FlightGear
|title  = November 2015, "Community Choice" Project of the Month – FlightGear
|author = SourceForge Community Team
|author = SourceForge Community Team
|date  = Nov 1st, 2015
|date  = Nov 1st, 2015
}}</ref>.
}}</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).
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 name="GUIquestions"/>.
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 name="GUIquestions"/>


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="GUItech"/>.
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="GUItech"/>


{{FGCquote
{{FGCquote
Line 265: Line 286:


=== FGRun ===
=== 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>{{cite web
One of the goals of the Qt launcher is to deprecate older frontends, like [[FGRun]].<ref>{{cite web
|url    = http://forum.flightgear.org/viewtopic.php?p=228961#p228961
|title  = Re: FG cannot be opened on new iMac
|author = Hooray
|date  = Jan 4th, 2015
}}</ref>, because James Turner is prototyping a Qt5 cross-platform GUI <ref>{{cite web
|url    = http://forum.flightgear.org/viewtopic.php?p=232593#p232593
|title  = Re: Request for a modernized FGRUN
|author = elgaton
|date  = Feb 20th, 2015
}}</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>{{cite web
|url    = http://sourceforge.net/p/flightgear/codetickets/1591/#4cb7
|url    = http://sourceforge.net/p/flightgear/codetickets/1591/#4cb7
|title  = Re: #1591 Restore defaults sets invalid paths
|title  = Re: #1591 Restore defaults sets invalid paths
|author = Gijs de Rooy
|author = Gijs de Rooy
|date  = Mar 8th, 2015
|date  = Mar 8th, 2015
}}</ref>.
}}</ref><ref>{{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>
{{DeQuote}}
|author=<nowiki>Hooray</nowiki>
 
|date=<nowiki>Tue Mar 17</nowiki>
{{FGCquote
}}</ref> At the time of writing (May 2016), however, it is still kept provisionally, and the user can choose whether to use the old or the new launcher. This is done for a variety of reasons:
  |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
* FGRun has more functionality than the Qt launcher;<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235167#p235167
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=240118#p240118
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |title=<nowiki>Re: Multiple aircraft versions not allowed in FGRun.  </nowiki>
|author=<nowiki>wkitty42</nowiki>
    |author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Mar 14</nowiki>
    |date=<nowiki>Thu Apr 23</nowiki>
}}</ref>
  }}
* it is still being debated whether Qt will also be used for the internal FlightGear UI, and to what extent (especially because there is partial overlapping with the Canvas framework);<ref>{{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>
{{FGCquote
|date=<nowiki>Tue Mar 17</nowiki>
  |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.
}}</ref>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235136#p235136
* UI integration will take some time, due to the need for legacy code to be refactored;<ref>{{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>
|title=<nowiki>Re: FGRUN I think it's useful add it in a standard way</nowiki>
    |author=<nowiki>F-JJTH</nowiki>
|author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sat Mar 14</nowiki>
|date=<nowiki>Tue Mar 17</nowiki>
  }}
}}</ref>
}}
* some building scripts still need to be updated.{{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>
{{FGCquote
|author=<nowiki>wkitty42</nowiki>
  |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
|date=<nowiki>Sun Mar 15</nowiki>
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=235178#p235178
}}</ref>
    |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>
  }}
}}


=== Python in FlightGear ===
=== Python in FlightGear ===
Line 434: Line 358:
}}
}}


== Testing ==
== Cross compiling using MingW64 ==
Any version of Qt newer than 5.1 works - we need to keep it backwards compatible and of course Qt is forwards compatible.
{{Main article|Building FlightGear - Cross Compiling}}
<ref>{{cite web
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.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=242914#p242914
|url   = http://sourceforge.net/p/flightgear/mailman/message/35020030/
|title=<nowiki>Re: [SOLVED] Install osgEarth feature on Win7 64b with FG gi</nowiki>
|title = <nowiki>Re: [Flightgear-devel] MSVC 2012 or 2013 support?</nowiki>
|author=<nowiki>hamzaalloush</nowiki>
|author = James Turner
|date=<nowiki>Thu May 14</nowiki>
|date   = Apr 17th, 2016
}}</ref>
}}</ref>
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>
(replace the name of the multiplayer server, the callsign and the visibility - in meters - as appropriate).
|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>{{cite web
|url    = http://sourceforge.net/p/flightgear/mailman/message/33646906/
|title  = <nowiki>Re: [Flightgear-devel] Download description page</nowiki>
|author = James Turner
|date  = Mar 26th, 2015
}}</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 ==
== Community Feedback ==
Line 491: Line 381:
   | script_version = 0.23
   | 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>
  }}
}}
}}


329

edits

Navigation menu