https://sourceforge.net/p/flightgear/ma ... /33245028/A heads-up announcement - I’m 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). When compiled without Qt support, you’ll get a fully functional FG (i.e, Qt will never be a requirement to build FG), but without the GUI functions - which is indeed what some people want anyway, e.g. some home cockpit setups.
https://sourceforge.net/p/flightgear/ma ... /35633931/The launcher UI is built using Qt, which is also my day job so I know it quite extensively.
https://sourceforge.net/p/flightgear/ma ... /34536197/One concern I have though, from the discussions over the last year, is
that the PUI->Qt migration plan is not a direct one-to-one migration.
I.e. to have a main Qt window providing the main FlightGear window by
containing a top menu bar followed by a QtWindow GL widget underneath,
in which the FG main execution loop is run as a thread from within the
Qt main loop. My impression was that the GUI will be a secondary
window or dialog that you have to switch to. But one problem I see
with this design is that all modern GUI toolkits (Qt, GTK, metro,
Cacoa, Carbon, etc.) suffer from racing and segfaulting issues if the
GUI main thread or main loop/event handler is not thread number 1.
https://sourceforge.net/p/flightgear/ma ... /34431801/Note that as the QtLauncher transitions into a full GUI to replace the PUI GUI, many of
these issues will disappear, and new ones will appear. In any case,
debugging a modern GUI is much harder than debugging the non-GUI
parts. A basic knowledge of threading, locks, and racing is quite
useful for understanding and catching these bugs.