QtQuick use in FlightGear
|This article is a stub. You can help the wiki by|
Note: For the most recent developments, please refer to the archives 
James coded up a Canvas QtQuick item for Qt replacing PUI (needs testing) since something like the map dialogs, makes no sense to do a new API for. So he expects we’ll use Qt fo the main UI (menus, dialogs, buttons, overlays like the MP pilot list) and emulating PUI, but we have the option to embed pieces of Canvas - for things like fuel / payload screens, map views or whatever.
The required Qt version was raised to 5.4 because it should have everything we need, API-wise.
The aircraft centre will be the first thing James is planning to switch to using the new Qt GUi, by sharing the QtQuick implementation with the launcher. Right now, he's modifying the appearance based on some feedback, especially from ThorstenR, and to expose more info. This will let me use the aircraft page as a proof of concept for the new UI system, and then test hosting the UI that way.
In January 2015, James Turner began prototyping (at the suggestion / encouragement of Curt, Torsten D & others) a GUI integration for FlightGear based on Qt 5. The goal is to make an *optional* Qt dependency to replace PLIB PUI. Except of course PUI will have to remain for some awkward use cases in the short term (aircraft dialogs, potentially).
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.
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.
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
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. 
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. 
On QtQuick in 2017
In May 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.
In 10/2017, James stated he is getting really close to having the PUI replacement UI suitable for beta-testing, so if this is for ‘nice to have’ things, it’s maybe not worth the effort.
James is hoping to land the PUI replacement GUI in last dev cycle in 2017 (at least as a proof-of-concept, probably not as the default UI), so wouldn’t expend lots of effort on things like collapsible sections which might be a lot of work with the current approaches, but are trivial with the new UI scheme.
Once the basic new UI is in place we can experiment with different re-arrangements easily, without being limited by PUI. (James expects PUI to live on as the default / alternate UI while this happens)