if you want to write C++ code, you will obviously have to patch/rebuild fgfs - so, it would be better to discuss this on the devel list.
On the other hand, if you have ever done any Nasal/Canvas coding, you have probably noticed that writing a Nasal parser to create a Canvas based menubar by processing menubar.xml is a rather straightforward exercise - and you won't have to write any low-level GL code, it's automatically using OSG under the hood.
So I guess, if someone were to spend 10 hrs coding in C++ to update PUI, the same 10 hours spent by someone working on the Qt5/QQ2 port would provide more bang for the buck, and obviously 10 hrs spent fine-tuning the pui2canvas parser, would provide a fast track solution to get rid of PUI without having to be a core developer, and even without having to touch any C++ code.
Then again, if people interested in an interim Canvas-based UI were to team up with C++ folks, much of the work of re-implementing the layouting/dialog builder routines would be obsolete, because FGPUIDialog.cxx could simply be adapted to override built-in widgets, analogous to how the addcommand() API makes it possible to register/override fgcommands implemented in Nasal.
There is already a mechanism in place to inherit from the abstract Canvas.Widget baseclass, this approach would also work to hook into the existing dialog builder, at that point you don't even have to deal with XML processing/properties anymore.
Again, if you want to write C++ code, it's best to reach out to the devel list, if all you need is a non-PUI menubar, that can be trivially accomplished via canvas, including fancy features like sub-menus, images, checkboxes etc
Writing a Nasal module to process our existing menubar.xml file to render a Canvas-based menubar would probably be less than 250 lines of code, it could be prototyped via the Nasal console, and once it works well enough it could be turned into an addon, so that people can easily decide whether they want to use that or not
Finally, there's more to PUI than the menubar, when I came up with the pui2canvas parser it was intended as a proof-of-concept because I considered the menubar far too trivial to make a point - many of the people back then, didn't even realize that there is already a built-in "Canvas GUI" system that supports windows, dialogs, event handling etc - as well as a handful of widgets and a really powerful widget API.
However, people not wanting PUI and those working towards a Qt5 based UI do have a very valid point, too: "coding dialogs" is begging for trouble, that is exactly the situation we reached by adding more and more Nasal blobs to our dialogs, if it wasn't for those, it would indeed be trivial to use _any_ other UI toolkit, it is the amount of Nasal code that is making matters more complicated than necessary.
The irony however is that thanks to the UI/Qt5 transition dilemma, we've already reached the point where aircraft developers no longer want to use PUI, and no longer want to "wait" for Qt5 - which means, they end up using Nasal and Canvas again, so that more and more aircraft are using fancy dialogs that are indeed not declarative but coded - ironically, that shields aircraft developers from the UI dilemma, but it also complicates any efforts to modernize our UI in the future.
Conceptually, having a declarative UI is the right thing - having Nasal blobs all over the place is hugely problematic, and so is "coding dialogs" without establishing logical boundaries, i.e. in terms of "layouts", "widgets" and "event handlers".
Admittedly, what some aircraft developers have meanwhile come up with is by far superior to what we have in the Canvas Widget department - the issue is, there is no encapsulation boundary, so that such dialogs are not designed with modularity or code reuse in mind.
But again, coming up with a handful of widgets to emulate those missing to get up to par with PUI (README.gui), is really comparatively straightforward in comparison to coding dialogs from scratch - most Canvas dialogs are easily more complex than the widget boilerplate needed to create/register new widgets.
I'd suggest, you take a look at some of the existing Canvas dialogs and widgets under $FG_ROOT/Nasal/canvas/gui to see for yourself:
wiki.flightgear.org/Howto:Creating_a_Canvas_GUI_Widget
For example, here's the code for the "Label" widget:
https://sourceforge.net/p/flightgear/fg ... /Label.nasThe parent class can be seen here:
https://sourceforge.net/p/flightgear/fg ... Widget.nasThe "view" part (MVC) of all widgets can be seen here:
https://sourceforge.net/p/flightgear/fg ... tStyle.nasSo the point really is, writing C++ code to do something that can be done in Nasal through Canvas/OSG without it being performance critical is kinda controversial, given that PUI is indeed scheduled to be phased out - i.e. be prepared to see your work going to the waste bin once the Qt5 stuff materializes