QtQuick use in FlightGear: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(https://sourceforge.net/p/flightgear/mailman/message/36064800/)
 
Line 58: Line 58:




== QtQuick in 2017  ==
== On QtQuick in 2017  ==
In 2017, James suggested to fix PUI for now, as he is still very much undecided about which technology to use for in-sim GUI, being somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is he 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. He 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 me nervous about multi-window setups and other more esoteric OSG configs. So, yes, do fix PUI for now, since this is worth a fairly quick fix as it’s the default airport.<ref>{{cite web
In 2017, James suggested to fix PUI for now, as he is still very much undecided about which technology to use for in-sim GUI, being somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is he 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. He 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 me nervous about multi-window setups and other more esoteric OSG configs. So, yes, do fix PUI for now, since this is worth a fairly quick fix as it’s the default airport.<ref>{{cite web
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35863607/  
   |url    =  https://sourceforge.net/p/flightgear/mailman/message/35863607/  
Line 68: Line 68:
   |script_version = 0.40  
   |script_version = 0.40  
   }}</ref>
   }}</ref>


== Related ==
== Related ==
{{Appendix}}
{{Appendix}}

Revision as of 19:42, 7 October 2017

This article is a stub. You can help the wiki by expanding it.

Note: For the most recent developments, please refer to the archives [1]

Background

There's been a strong division 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 hangouts in 2015, 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, Durk 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. For the record, Torsten Dreyer, who had just started working on phi, was also present at this meeting and agreed to this approach. For the time being, we see no conflict of interest here, as both of these approaches serve somewhat different purposes. Likewise, 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.[1]


On QtQuick in 2015

there will be an in-sim implementation of the current dialog system using Qt (probably QtQuick). It’s uncertain if this will use the current dialog XML files, or more likely, you’ll run those XML files through a translator script to produce a different file but which still essentially describes a dialog. Such machine-translated dialogs will look a little ugly but can then be incrementally improved and cleaned-up by humans. This version would be the ‘normal’ build that Mac / Windows users get, and at that point we’d presumably request (bot not require!) Qt on every platform /if you want an in-sim GUI/. The question would be if Qt isn’t found, do we simply say ‘okay, use the command line and Phi’ or what? Personally I don’t think expending effort making a ‘lite’ GUI is worth it, when Phi works so well and Qt is so widely available, but if people disagree we can discuss that. Creating a GUI from scratch will be plenty work, there are a couple of OSG efforts or someone could do everything using Canvas, but my life is too short for such tasks. This can be summarised as, if you want a GUI in your FGFS build, you need to use a GUI library, and that library is likely going to be Qt. (Again this is my opinion but I don’t think it’s controversial). If you don’t want a GUI you disable support at compile time or run-time and don’t pay any cost for loading / drawing a GUI.[2]

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[3]


On QtQuick in 2016

James said he was undecided if Qt Quick or widgets is the better way to go, with a preference towards Qt Quick, since it will allow things closer to current PUI (semi-transparent widgets on top of the 3D content). It still allows creating separate windows too (Erik’s use case), but means we get consistent, custom theming on all platforms, since standard desktop look is not so nice for a flight-sim. James intention is to make a QML-hosting OSG-drawable, and add this as a concept in Qt-enabled builds, then port some PUI dialogs to it, and see how easy / painful the process is. I’ll create some QObjects which expose commands and the property tree and Nasal. This has the advantage of not touching the OSG window at all, QtQuick simply provides some additional OpenGL rendering on top, which we pass events to - pretty much exactly the same as what we already do for PUI, and hopefully can co-exist with it. I have this working in a local OSG tree in a standalone demo, but that’s based on osgQt - he wants to see if I can make it work on a normal, non-Qt OSG window inside FlightGear. [4]

QQ2 would give better performance than regular widgets, although in any case the difference is irrelevant for FG. (Either will be ‘fast enough’) [...] James is not decided - widgets + a style sheet is another option, but then we can’t do transparent widgets efficiently (compositing windows with alpha over OpenGL windows /does/ incur a penalty on most OSs), and there are some ‘dialogs’ like the multiplayer list where transparency is really useful because they’re visible for long periods of time. [5]


On QtQuick in 2017

In 2017, James suggested to fix PUI for now, as he is still very much undecided about which technology to use for in-sim GUI, being somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is he 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. He 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 me nervous about multi-window setups and other more esoteric OSG configs. So, yes, do fix PUI for now, since this is worth a fairly quick fix as it’s the default airport.[6]

Related

References