Board index FlightGear Development New features

Any plans for a new GUI?

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Any plans for a new GUI?

Postby Zequinha » Sat Dec 03, 2016 6:59 pm

Hi folks,

Are there any plans for a new user interface in-game?

IMO, The one used in the game is a bit outdated and could do with a revamp!
Zequinha
 
Posts: 191
Joined: Sun Mar 13, 2016 4:26 pm
OS: GNU

Re: Any plans for a new GUI?

Postby wkitty42 » Sat Dec 03, 2016 8:59 pm

are you talking about the F10 menu bar??
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5568
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Any plans for a new GUI?

Postby Hooray » Sat Dec 03, 2016 9:28 pm

Well, the short answer is: yes.

The long, more detailed, answer is more controversial and demonstrates how complicated the whole matter really is.

FlightGear is using a built-in GUI engine using legacy OpenGL code (using PLIB's PUI): http://wiki.flightgear.org/PUI

On the one hand, this is providing the menubar, on the other hand it basically provides all the GUI dialogs and widgets.

For the time being, the only effort realistically able to "compete" with PUI is Torsten's mongoose/Phi work, because that's using industry standards like HTML5/jQuery (JavaScript): http://wiki.flightgear.org/Phi

However, that work happens to be "external" in the sense of having to be rendered by a browser (or GUI widget able to render DHTML).

Then, there is the ongoing Qt5 effort - this is the most solid approach at implementing a cross-platform GUI because that is really what Qt is all about. However, it doesn't come with the capability to render the GUI externally (as per Phi) - also, it is complicated to coax Qt5 code into an existing OpenGL application whose context it also didn't create originally, especially an multi-threaded application like FlightGear that happens to use all kinds of threads for different purposes, in conjunction with tons of legacy OpenGL code that isn't even using OSG (OpenSceneGraph) yet.

It would be much easier to start a new application from scratch with a Qt5 UI than integrating the whole thing at this point: http://wiki.flightgear.org/FlightGear_Qt_launcher

In addition, there are literally tons of legacy resources that must continue to be supported to /some/ degree - i.e. existing dialogs, some of which are dynamically/procedurally created, while others are outside the domain of fgdata/fgaddon (think aircraft specific dialogs).

This is where simply "porting" (as in "converting" or translating) existing dialogs is becoming hugely complicated.
The Phi approach is hitting significant challenges when it comes to supporting dialogs that contain tons of embedded FlightGear specific scripts (so called Nasal code).

Then again, given the current state of affairs, Phi is the most mature, and most promising, path forward - because it's inherently asynchronous due it its design - as far as I am aware, there isn't a single Phi/mongoose related feature that causes segfaults in FlightGear, whereas the history of the Qt5 integration is hugely different, despite having been tackled by one of the most experienced FlightGear core developers with an enormous track record when it comes to SimGear/FlightGear and Qt5 matters, the Qt5 code has been introducing tons of regressions in the form of segfaults and race conditions.

In addition, there is the issue of the Qt5 GUI component having to remain optional according to the original core developer consensus - whereas Phi is non-intrusive, i.e. there is no requirement to keep it optional.

All of this is massively complicating matters for anyone interested in porting/updating the legacy GUI in FlightGear, especially in the light of the relatively low importance/impact of the UI on people actually using the flight sim.

Besides, PUI inevitably must go sooner or later - simply because it's not playing nice with new/more modern OSG/OpenGL code, but for us to be able to get rid of PUI, we also must make sure not to cause any major regressions - no matter if that means retaining existing functionality, or retaining at least the same degree of accessibility (which is to say that people should continue to be able to modify/update and create GUI dialogs without necessarily having to be experienced C++ developers).

As far as I can tell, the work that lies ahead to properly port the existing UI to a new framework has been massively underestimated, and while Phi is very promising, it's also demonstrated that we cannot afford ignoring the DRY-principle, because otherwise we end up with diverging functionality among different UI approaches - e.g. imagine having to use Phi to control the space shuttle, having to use PUI to fly the 777 etc

Unfortuntely, there's not been much of a consensus (or holistic approach) between the folks working towards these solutions, despite original comments on designing, and providing a "common UI service layer".

What's been happening instead is that Qt5 is promoted, Phi is maintained and PUI is extended, i.e. new hard-coded PUI widgets are still added, which goes to show that neither the Qt5 nor the Phi work is anywhere close to actually "replacing" PUI in the sense of dealing with the in-sim use case.

Realistically, this means that there are some lessons to be learnt from this - e.g. by using Phi's approach at implementing am asynchronous UI using RPC/IPC in the form of non-blocking web sockets

At some point, this may mean that Phi may actually work for the in-sim use-case, too - at the mere cost of rendering a webkit view to a Qt widget and showing that inside FlightGear. However, that still would not deal with the core developer requirement to retain an in-sim GUI that does not require on optional depencies, unless this requirement is revisited and reconsidered.

Also, in the light of the challenges that the Qt5 integration has been facing, what would make more sense is wrapping a QWidget using a Canvas::Element sub-class - at which point, many issues would go away.

Finally, there's the original idea to get rid of PUI by implementing a parser in Nasal that dyncamilly interprets arbitrary PUI/XML markup to translate that into the corresponding Canvas equivalent, this idea is based on the realization that Canvas is all about 2D drawing, and that modern avionics are easily more complex than a standard GUI engine with a handful of widgets (in fact, PUI is rather archaic and simple in comparison to JavaScript/Qt5).

This whole idea was originally brought up by core developer James Turner, as part of his idea to help unify the 2D rendering back-end (2D panels, HUDs, GUI etc), so that legacy OpenGL code could be replaced and unified using a single back-end that ends up using modern OpenSceneGraph code.

More recently, the Qt5 effort has seen much more activity - however, the original proposal is definitely sound and implementing such a parser is not as much work as manually porting the whole GUI while retaining all existing functionality (checklists, joystick GUI, tutorials etc).

Basically, anybody not adopting the parser-based approach to deal with existing resources (including thouse outside fgdata/fgaddon) is basically deluding themselves when it comes to the degree of regressions that would sooner or later be introduced, unless the same person (or team of people) is also willing to re-implement all existing functionality accordingly, which is representing years of work by dozens of contributors.

For the nitty-gritty details, refer to: http://wiki.flightgear.org/Howto:Proces ... ing_Canvas

Image

(last I checked, that parser was somewhere close to ~500 LOC (living in fgdata), whereas the Phi/Qt5 efforts are a hugely different beast)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Any plans for a new GUI?

Postby Zequinha » Fri Dec 09, 2016 11:40 pm

Thanks Hooray,

I did give Phi a try on my Antergos (arch based) laptop. It runs smoothly but the rendering was carried out by the FGFS window and not Firefox. I specially liked the 'map' feature. It is easy to use and accurate (open street maps). Not only that but it also lets you set your aircraft position in such an easy way!

I found an extension for Firefox that maybe improves usability of Phi: Hide Navigation Bar. When you press F2, the URL bar and the buttons disappear.
Zequinha
 
Posts: 191
Joined: Sun Mar 13, 2016 4:26 pm
OS: GNU

Re: Any plans for a new GUI?

Postby wkitty42 » Sat Dec 10, 2016 5:05 am

in FF, hit F11 to switch to kiosk mode... hit it again to switch back... leave extensions alone... many of them open you to security violations...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5568
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Any plans for a new GUI?

Postby CaptB » Sat Dec 10, 2016 11:43 am

What exactly is wrong with the present GUI from the end user's standpoint? It delivers, it's simple and efficient with Phi available for anything else.

I would focus on improving PUI instead of reinventing the wheel especially that in a flight sim there is more interaction with the 3D model than with the GUI. In a flight sim I do not look at the GUI to enjoy how it looks, rather I want to get things done, in the most efficient and the least disruptive way possible and have it out of my way as it breaks my immersion ( XPX and FSX are offenders here with breaking immersion if you acces some things from the GUI )
CaptB
 
Posts: 520
Joined: Thu May 23, 2013 6:36 pm
Callsign: EKCH_AP
IRC name: CAPTB
Version: 2018.1
OS: Xubuntu, Win7 64

Re: Any plans for a new GUI?

Postby wkitty42 » Sat Dec 10, 2016 3:12 pm

FWIW: PUI is going the way of the dinosaur... slowly it is being replaced by canvas, IIRC...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5568
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Any plans for a new GUI?

Postby CaptB » Sat Dec 10, 2016 3:24 pm

wkitty42 wrote in Sat Dec 10, 2016 3:12 pm:FWIW: PUI is going the way of the dinosaur... slowly it is being replaced by canvas, IIRC...


That's nice, but canvas can be sluggish, compare the map dialogue responsiveness( zoom in/out ).
CaptB
 
Posts: 520
Joined: Thu May 23, 2013 6:36 pm
Callsign: EKCH_AP
IRC name: CAPTB
Version: 2018.1
OS: Xubuntu, Win7 64

Re: Any plans for a new GUI?

Postby wkitty42 » Sat Dec 10, 2016 3:29 pm

it isn't my doing, for one thing... yes PUI may be faster at some things but it is also much simpler and doesn't do a lot of things very well... canvas may need some optimizing but i would suspect that if canvas is being fed by nasal that the slow down problem is possibly more in nasal than canvas... especially if the nasal code is using props.cxx which has known problems and bottlenecks and is specifically not used by some craft (eg: shuttle)...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5568
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Any plans for a new GUI?

Postby Hooray » Sat Dec 10, 2016 5:01 pm

Sorry, but there's quite a bit of misinformation being spread here: PUI *has* to go because it contains/uses legacy OpenGL code that interferes badly with more modern OpenGL/OSG code, especially features using shaders/effects (do a forum search for "artifacts" to learn more).

Likewise, the performance issue related to the map-canvas.xml dialog pointed out by another user (when zooming) has nothing to do with Canvas or Nasal - it is C++ code that is causing this, and this is no surprise - it's a known issue actually. As a matter of fact, the hard-coded NavDisplay, as well as the hard-coded Map dialog both suffered from the exact same issue, until Gijs solved it by rewriting the projection handling code.

However, the original Canvas projection code is still using the old implementation, i.e. the update got never back-ported: http://wiki.flightgear.org/Canvas_MapSt ... erformance

We're talking here about roughly 50 lines of C++ code, which exist already and which would need to be turned into a Canvas::Map::Projection

Note that this would benefit any, and all, Canvas-based NavDisplay/Map applications, too - also note that this information is readily available in various places, so there is no need to draw any wrong conclusions or spread any misinformation here.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am


Return to New features

Who is online

Users browsing this forum: No registered users and 4 guests