Aircraft Center | pui2canvas parser (devel-list follow-up)

[bugman]

I would suggest having side-by-side screenshots of the PUI and CUI dialogs on the wiki article. It would be useful for tracking progress, graphic design, aesthetic layout, and how close to functional this is

Regards,
Edward

[Hooray]

yeah, that's a good idea - and one recently suggested to me in private - however, none of the screenshots is intended to claim that the UI is fully functional, a screenshot would be insufficient to "prove" that - it's really just demonstrating the completeness of the parser, not of any functionality mappings.

And I specifically stated that certain tags (widgets, and layouts) are ignored altogether - and the "n/a" label actually tells you so, too.

Referring to the "mammooth task" you mentioned, it is meanwhile pretty safe to say that it's less than a handful of widgets that are now missing to be able to approximate most PUI widgets/dialogs - it goes without saying that this won't look as good as a Qt5 UI, but it also won't have the costs associated with it - i.e. you could say, the pui2canvas approach is merely a simple fasttrack concept to get rid of PUI completely, without having to manually port any of the existing resources necessarily.

However, based on these experiments, I am actually in agreement with James' and Torsten's comments regarding the state of affairs in PUI/XML land: custom Nasal blobs should be actively discouraged, and probably discontinued/phased out sooner or later.
Well, I could make it show a big red rectangle whenever an unsupported widget is ignored ...

What is needed is an extensible file format to get rid of these constructs, so that they can be replaced with the corresponding layout/widget tags (think for tabs), as well as custom fgcommand implementations, which could then be shared among all front-ends. Sooner or later, this would end up being fully-declarative, and could be easily processed by all UIs - at which point a 1:1 Qt migration would be much less work, no matter if that involves procedural UI generation or semi-automated translation using some scripted approach.

What is currently taking place in PUI/XML space is hugely problematic for anything that does not run within the FlightGear process space and that does not have access to the Nasal subsystem, and that needs to change - for features like Phi/Qt etc to work, Nasal use must be encapsulated, i.e. delegated through some kind of "service layer" that is isolated from internals.

Anyway, Thorsten was right - it would be possible for a dedicated team of experienced Nasal/Canvas "hackers" to phase out PUI entirely, without causing tons of work - while I have been collecting a few ideas for improving the C++ interface of the Canvas code, I don't see many additions that are really required - it is one widget that James once added which is using data that is not currently accessible, i.e. the loglist widget - and we specifically talked about that a while ago, he ended up not quite sharing my view, so he moved on with its implementation - but otherwise, everything else can be approximated using a handful of additional widgets.

Besides, given that you are obviously interested in this, and given your wiki experience, you are obviously invited to help and come up with a corresponding table for those pui screenshots (or even the corresponding shots).

For example:


(It would take 5 LOC to actually show the initial state of each checkbox, it just hasn't been a priority so far)
But this dialog does contain embedded nasal code which procedurally modifies its own dialog tree to add/customize widgets, which is working correctly here.

However, I wasn't planning on regularly updating those shots - I was merely documenting some progress - let's keep in mind that the parser was laying dormant for the past 6+ months, so -in total- I still haven't spent more than a week's time of spare time hacking on it so far, i.e. have really only been motivated to resurrect it due to the recent events and debates, we've been having.

I have begun documenting some of the work that lies ahead: http://wiki.flightgear.org/Howto:Proces ... as#Roadmap
And I am also hoping to document useful C++ changes: http://wiki.flightgear.org/Howto:Proces ... C.2B.2B.29

As far as I can see the original proposal that James and Tom came up with is very solid, and the kind of work that I am doing is sufficiently straightforward that it would be possible for 1-2 dedicated contributors to bring the parser up to par with the PUI engine, but even the new Qt5 UI, without too much work.

But regardless of the outcome of this, this work is fairly self-contained and instructional for other reasons, i.e. helping unify the 2D rendering back-end (2D panels, HUD, splash screen, osgText animation) for better OpenGL compatibility, as per James' original proposal: http://wiki.flightgear.org/Unifying_the ... via_canvas

In other words, the whole approach could be adapted to also parse legacy 2D panels and HUD XML files to use modern OSG-aware OpenGL code, and any improvements to the lower-level C++ code would obviously not be specific to just the UI use-case.

[Hooray]

As for Qt being optional, over the last two years on the mailing list, that position has obviously evolved. I'm only stating what I see. And that is that it will be only optional for a tiny subset of people. The majority will use it, probably without knowing, as it will be the default GUI shipped with FG.

Just a little update, roughly ~12 months later, it seems indeed that bugman was right: the position on using Qt5 for the in-sim UI seems to have evolved (though, not exactly in line with bugman's original assertion a year ago):

https://sourceforge.net/p/flightgear/ma ... /35863607/

I would say do the PUI fix for now, I am still very much undecided about which technology to use for in-sim GUI. I am somewhat inclined towards using the Canvas, because it avoids some rendering issues (but exposes a few more, + some performance ones) but the problem is I am fairly unhappy with the GUI / widget API in the Canvas right now - it does not satisfy my ideas about how simple + robust such an API should be. I need to evaluate if the current API can be improved or needs to be drastically changed.

The other issue is to use QtQuick rendered into OpenGL, which has a very nice robust and well-designed API, but adds some dependencies and complicates the rendering architecture, which makes me nervous about multi-window setups and other more esoteric OSG configs.

So, yes, I’d say do PUI for now, since this is worth a fairly quick fix as it’s the default airport.

Kind regards,
James