FlightGear Qt launcher: Difference between revisions

Jump to navigation Jump to search
m
Line 52: Line 52:
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.
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.


{{FGCquote
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 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 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 back-end in FlightGear by getting rid of legacy GL code to hopefully use modern OSG code in more and more places: [[Unifying_the_2D_rendering_backend_via_canvas]]
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.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229311#p229311
    |title=<nowiki>Re: New Canvas GUI</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Thu Jan 08</nowiki>
  }}
}}


== PUI (legacy GUI) ==
== PUI (legacy GUI) ==

Navigation menu