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#RoadmapAnd I am also hoping to document useful C++ changes:
http://wiki.flightgear.org/Howto:Proces ... C.2B.2B.29As 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.