The following is just a guess based on some ongoing developments, and statements made on the devel list, so please take this with a good grain of salt.
However, it seems plausible that this could be related to the situation/developments described below, so that it would seem like a good idea to discuss this on the devel list, or at least make a proper bug report (issue tracker).
Full background at:
viewtopic.php?f=42&t=34597&p=339738&#p339738With the situation/timeline roughly being this:
Originally, the FlightGear UI (GUI) was using solely PUI (fixed function/pipeline OpenGL code):
http://wiki.flightgear.org/PUILater on, James Turner began porting/re-implementing certain dialog to use native OS APIs for Windows, Mac and Linux respectively.
This would include the "file open" and "file save" dialogs respectively.
With James being the primary (the only) developer interested in actively working on native platform behavior, primarily motivated by native Mac OSX "feel" at the time (as can be seen by numerous postings in the archives).
In addition, James has been acting as the de-facto lead developer of the project for the better part of the last decade - not just in terms of community involvement, but also in terms of track record, i.e. coding hours contributed to the project, number of commits and bugs fixed.
Should Torsten or Curt ever decide to take a step back, it's pretty clear that James would fill that role easily, whereas "replacing" James would not be as simple in comparison, because of the number of "hats" he's been wearing for so many years meanwhile. In other words, James has become the de-facto project coordinator/leader, simply because of his track record and his reputation among other contributors.
In early 2012, TheTom began prototyping/implementing a property-driven 2D API called "Canvas":
http://wiki.flightgear.org/CanvasJames ended up accepting Tom into the inner circle of core developers and provided him with commit access.
At the time, James, Tom and others agreed to use the Canvas to "unify the 2D rendering back-end in FlightGear" and re-implement the archaic PUI widget set on top of Canvas:
http://wiki.flightgear.org/Unifying_the ... via_canvasWith James stating explicitly:
James Turner wrote:http://www.mail-archive.com/flightgear- ... 37868.htmlI'm even more convinced now that we should move the 2D panel and HUD rendering over to this approach, since that would get rid of all the legacy OpenGL code besides the GUI.
http://www.mail-archive.com/flightgear- ... 37441.htmlThe long term idea is to eventually port some other 2D elements to this backend (eg the HUD and 2D panels) so they use OSG (and osgText) natively, and hence reduce the amount of C++ code we have for these jobs. (And increase our chances of working with newer OpenGL versions that forbid old style GL calls) Long-term here means 'after 2.8 at least'.
http://www.mail-archive.com/flightgear- ... 38629.htmlMoving the HUD to use the Canvas would be a great step from my point of view, since it and 2D panels (which I am happy to write the convert for!) are the last places besides the UI which make raw OpenGL calls, and hence would benefit from moving to the Canvas (and thus, to use OSG internally)
F-JJTH began prototyping a re-implementation of the built-in PUI based UI, and was encouraged to do so by James:
James Turner wrote:http://sourceforge.net/p/flightgear/mai ... /33055321/I actually considered the same, unifying many settings dialogs into one Preferences dialog; not combing ‘everything’ but all the Rendering / View / Multiplayer / Scenery Download / Instrument settings into one Preferences dialog with tabs.
Subsequently, James asked TheTom to implement a Canvas-based GUI front-end for his package manager back-end, which ended up being called the "Aircraft Center":
http://wiki.flightgear.org/Aircraft_CenterSumming up a google hangout, Curt stated:
Curtis Olson wrote:http://sourceforge.net/p/flightgear/mai ... /33451055/As we move forward with FlightGear development and future versions, we will be expanding the "in app" aircraft center. This dialog inside flightgear lets you select, download, and switch to any of the aircraft in the library.
TheTom then announced that all the piece would be in place so that a scripting-space re-implementation of PUI using Nasal/Canvas could be implemented, stating:
Thomas Geymayer wrote:http://sourceforge.net/p/flightgear/mai ... /32457866/The layout and widget systems is now maturing, so I think after 3.2 I
can start with porting PUI. Just one major component is missing, namely
keyboard input and the according input focus.
I guess this will take one or two more releases.
However, James then declared the Canvas-based "Aircraft Center" an experiment that would be a "dead-end", and actively discouraged people to work on GUI efforts not using Qt5/QQ.
The background here being that James Turner has been working on an integrated GUI launcher (fgrun replacement) over the course of the last 4-5 years:
http://wiki.flightgear.org/FlightGear_Qt_launcherThis launcher is using Qt5/QQ:
http://wiki.flightgear.org/QtQuick_use_in_FlightGearIn the meantime, James has been announcing over the course of the last 24 months, that he is also about to "finish" an initial PUI replacement using the same technology stack, and that this work is touching previous work he did on native OS windows, namely file open/file save dialogs.
In other words, what you are seeing might be related to the ongoing modernization of the internal GUI, where PUI may no longer be provided as an option, a potential issue that was extensively discussed here on the forum back when Qt vs. Canvas seemed like an option.
To be fair though, I haven't been following FG development much recently, but James also mentioned concerns every once in a while, even suggesting that he's leaning towards a Canvas based approach (once again):
James Turner wrote:https://sourceforge.net/p/flightgear/ma ... /35863607/As of 05/2017, James is still very much undecided about which technology to use for in-sim GUI, he is somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is James 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, James 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 him nervous about multi-window setups and other more esoteric OSG configs.[