FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??

[Hooray]

Actually, as can be seen in this thread, Torsten has been working towards a HTML5/JavaScript based GUI solution...

[onox]

Actually, as can be seen in this thread, Torsten has been working towards a HTML5/JavaScript based GUI solution...

That's the separate fgpanel, right? I'm talking about replacing the in-game PUI GUI with something better. If you want to use HTML5 for that, you're gonna need a built-in HTML5 engine like webkit. I don't think that's a good choice unless you want to blow up RAM usage.

[Hooray]

Actually, see Torsten's original announcement: for the time being his work is intended to be an alternate UI that will be external and browser-based.
We've had a few webkit related discussions, too - basically sharing your concerns.
Then again, compared to Qt, webkit is a relatively lightweight dependency - equally, webkit is already supported by an OSG plugin, too.
But that was never the point/focus of Torsten's announcement: viewtopic.php?p=228281#p228281

The real problem is that with so many overlapping UI efforts, there are only very few opportunities to collaborate properly, because people are pulling into hugely different directions.

[Hooray]

http://sourceforge.net/p/flightgear/mai ... /34534194/

/Another/ option is we optionally host /all/ of Phi in an embedded Qt-webview [or even a non-Qt solution for embedding a web browser, but I don’t think that exists] inside FlightGear, and make a re-style that looks more like a normal GUI than something web-based.

Subject: BROWSER MP-MAP plotted on a MFD somebody?

yeah, there's even code in $OSG_SRC/examples doing exactly this, i.e. rendering a fully interactive webkit-browser to a texture. But all those dependencies are not really relevant to FlightGear. Also, there would be quite a bit of redundant stuff added, which we don't even use in other places.

Subject: GUI Styles vastly ignored, Why ?

Concerning the other two UI efforts going on (web UI and Qt5), there remains one issue that need to be addressed in order for either of those to be considered a viable alternative/replacement for PUI or the Canvas UI (a GUI running inside the main FG process/window): dependencies i.e. accepting WebKit, and especially, Qt5, as build-time dependencies for all platforms would need to be thoroughly discussed on the devel list to arrive at some consensus. And looking at how divided the FG community was in early 2006 when Mathias started adding OSG, or when Tim started adding boost - it is foreseeable that consensus will be hard to establish ...

Subject: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??

For Torsten's work to literally conflict with the Canvas GUI effort, he would have to find a consensus among core developers to accept WebKit as a dependency into FlightGear (which is available as an OSG plugin), i.e. so that the mongoose GUI would also work as an integrated UI. Equally, rendering internal cameras (MFDs, instruments or scenery) is going to be challenging for anything external, unless you only want to display a "stream".

So yeah, there's /some/ competition in the house - but it's not a bad thing per se, and it also isn't uncommon for FlightGear to have a bunch of incompatible/mutually-exclusive features (think FDMs, scripting solutions, systems modelling blocks, weather systems etc), with different people believing in different approaches.

[Johan G]

Regarding FGRun/Qt5/Phi/third party front ends I start to see that we are about to do something that is... not that new:


xkcd #927: Standards

Somehow I think it has more to do with how maintainable the existing solutions are rather than the real needs (which still are there of course).