2,732
edits
FlightGear Qt launcher: Difference between revisions
Start doing full references (as opposed to just URLs). Also combine duplicates
Red Leader (talk | contribs) (→Background: Refs) |
Red Leader (talk | contribs) (Start doing full references (as opposed to just URLs). Also combine duplicates) |
||
| Line 46: | Line 46: | ||
* 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>{{cite web | However, it should be made clear the 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 80: | Line 80: | ||
}} | }} | ||
}} | }} | ||
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>. | For the time being, Qt is only needed for the launcher feature, which is automatically disabled if it is not found<ref>{{cite web | ||
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). | |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>. | |||
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/ | |||
|title = <nowiki>Re: [Flightgear-devel] Qt launcher requirement bump in Flightgear | |||
git</nowiki> | |||
|author = Bertrand Coconnier | |||
|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). | |||
On systems without Qt5 support, you will see this: | On systems without Qt5 support, you will see this: | ||
| Line 105: | Line 117: | ||
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). | 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> | 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> | |||
=== Segfaults & race conditions === | === Segfaults & race conditions === | ||
| Line 124: | Line 141: | ||
}} | }} | ||
}} | }} | ||
=== Canvas === | === Canvas === | ||
| Line 143: | Line 158: | ||
}} | }} | ||
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=" | 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/ | |||
|title = <nowiki>[Flightgear-devel] Gui technologies</nowiki> | |||
|author = James Turner | |||
|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. | |||
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). | ||
| Line 149: | Line 169: | ||
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>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. | 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 | |||
|title = <nowiki>Re: New Canvas GUI</nowiki> | |||
|author = Hooray | |||
|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. | |||
=== Duplicating existing functionality === | === Duplicating existing functionality === | ||
| Line 187: | Line 212: | ||
=== 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 | 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>http://sourceforge.net/blog/november-2015-community-choice-project-of-the-month-flightgear/</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>. | ||
| Line 193: | Line 218: | ||
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 | 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=" | 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 233: | Line 258: | ||
}} | }} | ||
}} | }} | ||
=== FGRun === | === FGRun === | ||
| Line 242: | Line 265: | ||
{{DeQuote}} | {{DeQuote}} | ||
{{FGCquote | {{FGCquote | ||
| Line 292: | Line 314: | ||
}} | }} | ||
}} | }} | ||
{{FGCquote | {{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/> | |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/> | ||
| Line 303: | Line 326: | ||
}} | }} | ||
}} | }} | ||
{{FGCquote | {{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/> | |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/> | ||
| Line 339: | Line 363: | ||
}} | }} | ||
}} | }} | ||
{{FGCquote | {{FGCquote | ||
| Line 350: | Line 372: | ||
}} | }} | ||
}} | }} | ||
=== Python in FlightGear === | === Python in FlightGear === | ||
| Line 487: | Line 506: | ||
== Issues and limitations == | == Issues and limitations == | ||
Note that even in the optimistic case, there will be some limitations – e.g., multi-window setup will not work in Qt builds without further work<ref name=" | 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="GUItech"/>. | ||
* [http://forum.flightgear.org/viewtopic.php?f=22&t=26504#p246868 Airplane is in FG root, can't see in flightgear wizard] | * [http://forum.flightgear.org/viewtopic.php?f=22&t=26504#p246868 Airplane is in FG root, can't see in flightgear wizard] | ||
* {{bug|1772}} | |||
{{FGCquote | {{FGCquote | ||