[Flightgear-devel] GUI questions (again)

[James T. <zak...@ma...>]

> 
> On 11 Oct 2015, at 05:53, Thorsten Renk <tho...@sc... <mailto:tho...@sc...>> wrote:
> 
> Sorry, but since this keeps coming up in the forum - could someone who 
> has a strategic plan perhaps clarify things for me once more:

Well the first thing to know is there might not be a strategic plan at all :)

> 
> I understand that there's a Qt5 launcher in the making which Durk 
> described here as
> 
> "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."
> 
> This seems to be the thing James decribed as
> 
> "The in-sim GUI (i.e. 'aircraft center') should probably be considered 
> an experiment which won’t be
>  developed further - while it was being created, the core developers
> agreed that use of Qt to provide ‘out of window’ GUI was reasonable.
> At some point (possibly quite soon) I’ll enable a version of the Qt 
> launcher
> to be triggered from the in-sim menu (but as a separate dialog), at 
> least
> an an experimental feature."
> 
> So this sounds a bit like an FGRun++, i.e. something that provides 
> launcher and controller functionality - as a technically extra program 
> in a separate window (a bit like Phi, just not via http) but integrated 
> in a way the normal user won't realize what it technically is.
> 
> Is that correct?

The Qt launcher / GUI isn’t a separate executable, it’s built into fgfs.exe /if requested at compile time/, and it’s explicitly optional.

> If so, is this functionality envisioned to be optional or not, i.e. do 
> we sooner or later require Qt5 for all practical purposes even when 
> technically only for a module as Durk said (because we otherwise won't 
> have a GUI at all) or is this really like FGRun something that users 
> (who perhaps know how to type a command line or a shell script)  don't 
> absolutely need and can add optionally to their build environment?

Correct, the intention is we’re adding integrated convenience features but the command line / shell environment won’t change and the default mode of ‘fgfs’ even in a Qt-enabled build is unchanged. You need set an env var or pass an argument to get the launcher, even if the feature was selected at compile time.  We have the advantage that the Windows and Mac pre-built builds, it’s easy to ensure Qt is available, and those users are less likely to want complex command-line control than Linux users.

There is 100% agreement that FlightGear will never require Qt, the only question is if the GUI requires Qt, which brings us to your final point:

> 
> Likewise, what is the expected fate of the in-sim GUI - specifically 
> thinking for instance about custom aircraft dialogs (I have a lot of 
> them in the Shuttle...)? Will those also be replaced by an out of window 
> GUI, will we keep the current one as a fallback, will we have to port 
> them to something else?
> 
> What is the idea with respect to canvas-type aircraft specific GUI 
> elements (the Shuttle groundtrack map,...) in the future?
> 
> Are we all imagining the same thing when we say GUI, or are some people 
> imagining the launcher-type functionality (select aircraft and location, 
> select weather, manage packages,...) and others the APU/Hydraulics 
> dialog of an aircraft?

/My/ feeling is this, this may not be everyone else’s:

- there should be a ‘non-GUI’ build which does not need Qt, where there is no GUI / dialogs at all. This solution can have full control of the sim via Phi / sockets / remote properties. It would have no PUI dependency and be very good for kiosk and bunch of other use cases. (projectors, sim-pits, second monitors)

- 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.

- even if Qt is selected at compile time, it will still be possible to disable it at run time. That’s important because /initially/ it’s likely that some window-setup features won’t work when using Qt. Especially the multi-window options for handling different projectors side-by-side. 

- 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 but I don’t see any benefit there - the non-Qt builds still need Canvas support for flight-displays and the like)

Note the current solution based on PUI really needs to go away for plenty reasons, especially the horrible OpenGL code it runs.

Just to emphasise again, this is my thoughts, I’ve shared them with other folks previously and been told it seems reasonable, but it’s not ‘official policyt’. 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.

Kind regards,
James