QtQuick use in FlightGear
| FlightGear Frontends |
|---|
|
Startup |
|
Internal
|
|
External
|
| This article or section contains out-of-date information
Please help improve this article by updating it. There may be additional information on the talk page. |
Note: For the most recent developments, please refer to the archives [1]
Status
|
|
| Note Update 09/2022: The PUI replacement was going to be Qt but it started to get very complicated with changes in Qt 5.15 + Qt 6, so James is going with a more light-weight approach now.
Qt added support for Vulkan / Metal / D3D starting in 5.15, but FlightGear / OpenSceneGraph can’t support those, so integrating the two renderers went from being ‘complicated but ok’ to ‘very very complicated’. (If for some reason anyone wants the code to render Qt Quick in OpenGL mode into OpenSceneGraph, I have it working nicely on a branch, from about two years ago...) So now James is now going with something much lightweight using some C++ compatibility code, some Nasal for styling and the existing widget rendering from Thomas Geymayer (TheTomo) with some extensions and additions: some pieces are in FlightGear & FGData already. James has basic dialogs working okay but not the more complex ones and everything looks kind of ugly, he needs to improve the visual look before he shares screenshots to avoid everyone freaking out :) The disadvantage of this approach is James is far from expert at creating visual appearances this way, so it’s kind on unrewarding and slow for him. If someone likes messing with CSS-type styling, border-images and hover-states, ping me since we could probably move things also faster [1] |
Background
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).[2]
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.[3]
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.[4]
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[5]
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. [6]
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. [7]
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.[8]
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.[9]
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.[10]
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)[11]
On QtQuick in 2018
PUI we’re using at the moment but has some bugs as noted, but James is making good progress towards the new UI, and we’re already close to the point where PUI is optional at both runtime and compile time.[12]
There is some divided ideas on the way the 2D UI in the sim should go, but for avionics and heavily-styled dialogs Canvas is certainly the best option. (For example, a custom fuel dialog for an aircraft, with a clickable diagram of fuel tanks and valves)
The launcher uses Qt widgets but is moving to QtQuick, so that it’s easier for non-C++ developers to contribute to - and James plan is to then use this same QtQuick UI inside the sim, to replace PUI.
This will involve consolidating several of the current dialogs, into a more modern UI structure. Help with this will be appreciated when the basic structures arrives in the next couple of months.
(We will likely also keep PUI as a compile-time option, or even run-time option, for a while when the Qt UI arrives, since Ui changes tend to need a while to mature and figure out everyone’s uses) [13]
On QtQuick in 2019
the launcher is now feature complete with the QtQuick UI[14]
On QtQuick in 2020
We don’t actually have ‘disable launcher’ : the launcher is strictly opt-in. On Windows and macOS that’s achieved by the shortcuts/bundle, which request fgfs to run with the launcher.[15]
To build on Windows, you want the Qt open source license, but you don't need to build Qt from source. Search for... Qt Online Installer 3.2.3 [16]
Recommend you install Qt 5.15.0 Desktop + Scripts. I don't think the other Desktop components are needed.
Leave the default Developer and Designer Tools selection - these are needed for coding and compiling.[17]