FlightGear Qt launcher: Difference between revisions

James Turner is currently prototyping (at the suggestion / encouragement of Curt, Torsten D & others) a GUI integration for FlightGear based on Qt 5. This would overlap some areas other folks are working on, so we felt it best to make an announcement to avoid anyone expending their time on areas that might be affected<ref>http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>.

This will be an in-app launcher for Mac initially, based on Qt5. Primarily, because the old Mac launcher doesn’t work on Yosemite, so we are adding a tiny Qt-based launcher inside the main process (no need to fork / exec) which runs before the OSG window is created, this will be merged for 3.4, hopefully with no impact on other platforms.<ref>https://gitorious.org/fg/flightgear/commit/78e8f533124ad38c414d10470abcd2149b6d01e8#src/Main/main.cxx</ref>

All of this would be a QtQuick 2 GUI, not a Qt widgets GUI. If you don’t know what that terminology means, don’t worry about it, the quick answer is it works the same ways as Canvas does at present (rendering to OpenGL).

For now, 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.

Expect to see a test branch in Git in the next month or so, and hopefully something usable for 3.6. Note that even in this (slightly optimistic) case, there will be some limitations, e.g. multi-window setup will not work in Qt builds without further work. The PLIB code will remain so hopefully it can be a gradual transition<ref>http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>.

 

Some code James has written in the 2014 will be obsolete, e.g. the native message box and menubar code. James isn't expecting many issues integrating Canvas layers with a Qt GUI, so there is no wasted development effort there (There is the possibility to make a Canvas backend based upon QPainter, which might be a great way to use spare CPU cycles to unload the GPU, however, as Canvas rendering becomes more intensive)<ref>http://sourceforge.net/p/flightgear/mailman/message/33245028/</ref>.