@bugman: Regarding your other posting, given that you are mainly stating views and opinions here, I would suggest that you actually review the corresponding discussions in the archives - it's not that this is a long overdue discussion, it has taken place years ago, and what you have posted now looks like a pool of questions that could be easily answered by referring to those topics, or even just by reviewing the pointers collected in the pui2canvas parser article; there really are too many conceptual issues in your posting currently.
Likewise, I am not asking you, or Thorsten, to communicate my perspective to James, Torsten or others - had you looked up the corresponding topics, you would have noticed that James himself made these exact same points several years ago, so I am merely rehashing the original core developer consensus back then, and posing the question whether it is fair to claim that this stance has "evolved" and that many of the original technical arguments made back then, are simply no longer applicable.
Besides, thanks for clarifying why you're using "CUI" as an acronym, but I did realize why you used it, I just STILL don't know what you want it to stand for - honestly, and without meaning to offend, I am not getting the impression that you are commenting here on something that you really understand, despite a number of postings, and pointers, posted to provide the relevant background information - information that would be valuable even if you ignored everything that I have said and written about the topic.
Like I said previously, there are different components available in FlightGear - as in an existing "Canvas GUI" SGSubsystem that runs inside the main loop, which all Canvas code can leverage - aside from that, there are widgets, and a framework to easily create new widgets - including a SVG parser that can reuse JavaScript/HTML based widgets.
Apart from that, there is the pui2canvas parser that maps a subset of the legacy PUI markup to this existing infrastructure.
Trying to encourage me to participate in the devel list, you have told me more than once previously that my signal-to-noise ratio would be exceptionally good in this case, because I am actually familiar with the corresponding C++ and Nasal modules (PUI, Canvas and to some extend Qt5/launcher), and have actually come up with code that just works - thus, I don't quite get why you are not simply reviewing the pointers that I have posted to make up your own mind - as far as I can tell, there's a huge disconnect between the different concepts and ideas brought forward here.
For instance, just look at your comment regarding James not taking up the pui2canvas parser: That was never the point of what I said, I specifically referred to the Canvas GUI SGSubsystem, referring to the challenge of rendering a Qt5 widget into the existing FlightGear OSG/OpenGL window - I said, that this is exactly what the Canvas system has successed doing, like ~5 years ago - and that this would be the best/easiest option to make the Qt5 stuff work inside FlightGear - totally unrelated to pui2canvas or PUI specifically.
Please, do me a favor and at least try to do some reading prior to making these bold and authoritative postings, especially if you otherwise end up bailing out claiminig that you're just posting your "views" and "opinions" - in that case, it would make much more sense to pose those as questions. What you have done so far in this discussion (excluding your last posting) is making it all sound decided and final - whereas the opposite is the case.
I do realize that you are trying to interface between the forum and the devel list, but for that to succeed, you really need to understand the concepts and ideas you are juggling here, or you are just adding to the confusion.
Bottom line, the Canvas UI SGSubsystem is there, it's existing C++ code, that has been integrated years ago - it's used every day - whenever you're seeing a tooltip, a Canvas GUI dialog or a CanvasWidget, it's all there and just works.
If people find it challenging to render a webkit or Qt5 widget into FlightGear, they'd be well-advised to simply come up with a custom Canvas::Element child class - which I also understand how to do, and James has previously done that, too (he implemented/prototyped Canvas::Image for handling raster images), so he understaands perfectly how to extend the Canvas system to support other "elements".
This path is unrelated to PUI or pui2canvas - it's just a way of rendering into the FligthGear window, without having to do much homework - it'll just work, which includes event handling etc - Tom implemented that almost half a decade ago, indeed at the encouragement of James and others back then ...
It is how I prototyped support for rendering PDF files and 3D models to a Canvas:
Finally, the replacing the PUI menubar with a Canvas-based one is trivial - the code on the wiki actually worked, i.e. is parsing menubar.xml and creates buttons that create popups with the corresponding entries.
Anyway, I have tried to kept this positive - realizing that you're trying to be part of the solution and not the problem, but the degree of misinformation you're spreading is not exactly encouraging, and I am frankly annoyed by that, especially given that the facts are not just there in the form of devel list postings, but actual commits and code in SG/FG proving you wrong.
The way you have introduced the CUI acronym, and been using it, you are hugely misrepresenting the state of Canvas affairs in FlightGear - especially because that has zero to do with the menubar or pui2canvas efforts.
In summary, the pui2canvas effort does not need to be used, supported, endorsed or even just reviewed/committed by any core developers, because it's just a tiny, and optional, Nasal/Canvas module that can be added to fgdata by fgdata contributors - or even just distributed as a self-contained Nasal module that can be dropped into $FG_HOME/Nasal - and it just works, so there really is no "disconnect" or "communication barrier" here - that debate took place years ago, and James himself came up with most of the ideas related to this, we're really just implementing his original proposal - regardless of his Qt5 work, and regardless of his current priorities - he not only came up with these ideas, but approved them and encouraged this work, just like he encouraged the development of the Canvas based aircraft center
So please stop spreading all this FUD, and consider reviewing what has been said and done so far - and you would notice that the Qt5 launcher simply cannot reuse any Nasal/Canvas stuff due to the
reset/re-init system not initializing Nasal early enough.
So far, it's been implemented as a startup option that isn't well integrated with the main loop or other SGSubsystems - thus, nasal/canvas are only just about to become actual options here.
And it's typical OSS-"surival of the fittest" that will prove which approach is superior in terms of workload and resources/expertise required to implemend and maintain these features in the mid-term. Thus, I absolutely share Thorsten's view - and I do know to implement everything that Thorsten would like to see, without it causing tons of work, which is why his comments were spot-on: If people really wanted to get rid of PUI, it can be done fairly easily and quickly, without requiring any support/endorsemeent from any core developers - regardless of efforts that they consider competing/conflicting by their nature