Talk:FlightGear Qt launcher

To be incorporated

You /can/ set the download dir via the launcher, and the default TerraSync dir is $download_dir/TerraSync, so this is intended to make setting the TerraSync dir manually unnecessary.

the launcher itself never sets —terrasync-dir, only —download-dir. And if both are set, —terrasync-dir is used of course. So if you set —terrasync-dir manaully in additional settings, its value will be used.

Based on recent discussion and confusion, I just pushed some changes to the launcher. I would appreciate testing and feedback on the exact wording, I am trying to avoid confusing users and encouraging novice users to change things they should not, while still giving advanced users the flexibility they need. - the ‘add-ons’ dialog is now a fourth page (tab), which solves some odd interaction problems and hopefully makes the ‘where is this setting’ more coherent the ‘restore settings’ button on the settings page now explains what it does more clearly, and warns that it will disturb the download and data settings. I *could* tweak the code to preserve the values of those settings but wipe all others, but that seems very baroque, so I prefer to simply warn users what will happen. adjusting the data path (which is now described as ’fg-data’) does not affect any other setting - there is more descriptive text in the add-ons page about what the data and download directories are for, and the consequences of changing them. Launcher settings are stored in .ini format in $FG_HOME/flightgear.org/FlightGear.ini The one missing piece is if you change the download dir, and hence lose the default / official aircraft hanger, there is is no UI to explain what you only have the C172 and UFO. I intend to add this to the aircraft list as a custom item (which can be dismissed), stating something like: [No aircraft hangars or folders are defined, so only the default aircraft are available. Use the add-ons page to add hangars or select aircraft folders, or <click here> to hide this message] Again, feedback on *all* of this wording is welcome, since what makes sense to me may not make sense to everyone. Please note I will probably reject /any/ wording or language which contains the following ‘path’ (generally I’m using ‘location’) ‘environment variable’ (avoiding mentioning these at all!) ‘executable’ (use ‘application’ or ‘program’ or ‘FlightGear’) ‘directory’ (use ‘folder’) All feedback and testing is much appreciated. — James Turner (Apr 8th, 2016). [Flightgear-devel] Launcher add-on handling changes. (powered by Instant-Cquotes)

I've added a remark about the fact that it is now unnecessary to set the TerraSync download directory explicitly and the path change for the launcher settings; I'm not sure, however, how to phrase the --download-dir vs. --terrasync-dir difference, and I wonder if it's worth including the remarks James made about the Restore settings button and the FGData path adjustment, as they are meant to be self-explanatory (I fear it only adds complexity to the page). What do you think? -- ElGaton (talk to me) 05:49, 1 May 2016 (EDT)

replacing plib UI with Qt5

@Red Leader: The reference used there is referring to the draft published originally (discussed on the devel list), since then, a number of senior contributors have explicitly stated that Qt is intended to always remain optional and that an integrated UI has to be provided for the non Qt use-case (and James confirmed that).

Looking at the current integration, none of the QT code is integrated in a way to be invoked at runtime:

GUI/CMakeLists.txt:72:if (HAVE_QT)
GUI/MessageBox.cxx:34:#ifdef HAVE_QT
GUI/MessageBox.cxx:129:#elif defined(HAVE_QT)
GUI/MessageBox.cxx:148:#elif defined(HAVE_QT)
GUI/FileDialog.cxx:44:#if defined(HAVE_QT)
GUI/FileDialog.cxx:154:#elif defined(HAVE_QT)
Main/fg_commands.cxx:61:#if defined(HAVE_QT)
Main/fg_commands.cxx:994:#if defined(HAVE_QT)
Main/options.cxx:58:#if defined(HAVE_QT)
Main/options.cxx:2517:#if defined(HAVE_QT)
Main/options.cxx:2535:#if defined(HAVE_QT)
Main/main.cxx:84:#if defined(HAVE_QT)
Main/main.cxx:445:#if defined(HAVE_QT)
Viewer/WindowBuilder.cxx:28:#if defined(HAVE_QT) && defined(SG_MAC)
Viewer/WindowBuilder.cxx:256:#if defined(HAVE_QT) && defined(SG_MAC)

So unless there's been a recent update/consensus here, I don't think the current wording is sufficiently accurate, certainly not in the light of the architecture/threading related observations made by a number of contributors.

The launcher itself is totally separate from the FlightGear main loop, and such does not have any immediate effect on the runtime UI (at least for the time being). I think, we'd be hard pressed to find specific statements supporting this - so if you want to keep this in the article, it would be a good idea to ask for clarification on the devel list, or at least add supporting statements from other core developers.

In fact, the most recent comments regarding PLIB/PUI reiterate the idea to absorb the relevant PLIB components into SimGear, and even James himself continues to make commits that would conflict with a Qt5 runtime UI.

Honestly, with these recent comments, and PUI related commits, in mind, I think it is only fair to suggest that the workload of actually porting the existing UI to Qt5 in its entirety has been hugely underestimated, especially in the light of all this work having to remain entirely optional (see Durk's and Rebecca's comments).

If you are aware of any other developments, I suggest to add the corresponding pointers - I have been maintaining a list of relevant statements at [1]

--Hooray (talk) 07:39, 30 April 2016 (EDT)