Difference between revisions of "The FlightGear Front-End Situation"

Latest revision as of 06:22, 25 November 2020

Background

Many users do feel a need to improve the current situation, can be seen by the multitude of GUI front-ends that have been developed for FlightGear during the last couple of years.

I've been troubled by the GUI since we entered the computer age. I too wanted to contribute to bring it into the 21st Century. This is one area that it seems there may be some competing interests, or at least overlapping and it is unclear as to what will come out the other side, at least to us uniformed users. If there is a solid road map, now would be a good time for those who are in the know to spell it out. — wlbragg (Thu Feb 26). Re: GUI . (powered by Instant-Cquotes)

Just for the sake of completeness and to avoid misunderstanding: There is a lot of coordination and communication going on between most "core developers". Just a little bit of this is visible as we sometimes meet face-to-face and much more often voice or video-chat. The parallel development of HTML and Qt based UI happens by intention and is not the result of missing coordination. Torsten — Torsten (Sat Jan 10). Re: New Canvas GUI. (powered by Instant-Cquotes)

There's been a strong devision of opinion among a couple of core developers with respect to the question whether a QT dependency is desirable or not. — Durk Talsma (Jun 11th, 2015). Re: [Flightgear-devel] Policy Document and V4.X Roadmap. (powered by Instant-Cquotes)

We concluded that a QT dependency was undesirable, unless it had a specific benefit. — Durk Talsma (Jun 11th, 2015). Re: [Flightgear-devel] Policy Document and V4.X Roadmap. (powered by Instant-Cquotes)

In fact, in 2006 there were reported to be at least five different GUI launchers available for FlightGear [1]:

• Fgrun
• KFreeFlight
• MacFlightGear
• FGTools
• JFlightWizard [2]
• fgkicker
• FGWALK[3]
• FGo!
• FFGo
• FG Flier
• FGStartup
• FGX
• Yaflight
• Temporary Yosemite Launcher (added 12/2014)
• Integrated Qt5 launcher for Mac (see above, adds Qt5 dependency)
• Canvas GUI (no added dependencies whatsoever)

All of which supporting different functionality/features, having different library/system dependencies and being different code bases, with little -if any- reuse of existing code, all of which serving however the very same purpose of providing: a GUI frontend for FlightGear.

Furthermore, plans to develop even more new frontends in addition to the plethora of existing ones are still being discussed [4].

As has been pointed out in the original discussion [5], this pattern is a not only a very unfortunate one, but also a recurring one - which is also likely to drain development resources from FlightGear itself - simply because a number of developers and potential contributors spend time developing redundant software that wouldn't need to be developed in the first place if the FlightGear design were to be fixed so that the key facilities provided by existing launchers would be directly supported by FlightGear itself.

While it was pointed out in one case that the reason for yet another FlightGear GUI frontend, was motivated by non-technical reasons (such as native/platform "look & feel"), all other remaining reasons for developing these launchers were indeed technical ones, meaning:

None of these standalone frontends would likely need to be in existence today if FlightGear itself featured a native, built-in GUI frontend

Indeed, FlightGear's cross-platform nature obviously provides additional challenges for developing standalone launchers, so that some launchers may only work on specific platforms.

So, the most natural thing to do would be to directly integrate these facilities into FlightGear, where they can make use of extensive FlightGear APIs that are known to compile and work across all supported FlightGear platforms.