This topic should have been moved to a different forum obviously, given that it's about PUI and not Canvas.
Anyway, for the sake of completeness, there is an existing "checkbox" widget for the Canvas system - Tom implemented a dedicated canvas/widget API when he created the "Aircraft Center" Canvas dialog:
http://wiki.flightgear.org/Aircraft_Center
This includes support for buttons (a checkbox really being just a toggle button after all, just like a radio button):
http://wiki.flightgear.org/Canvas_Snipp ... Layouts.29
Using the existing "canvas checkbox widget" it is trivial to take an existing PUI/XML dialog, and load/parse that to map those <checkbox> tags to their corresponding Nasal/Canvas equivalent:
http://wiki.flightgear.org/Howto:Proces ... ing_Canvas
Note that this indeed done procedurally, i.e. at runtime - the original PUI/XML dialog wasn't touched to create the Canvas equivalent.
The parser can be also incrementally fixed up to support more complex dialogs, by adding hooks for the widgets currently missing.
For example, the screenshot shown below renders a fully-functional equivalent of map-canvas.xml which contains embedded Nasal/Canvas blobs, and which are correctly handled:
Both, Josh and Thorsten made a number of valid observations/points - however, the point being, dialogs shouldn't need to be "coded" at all. A number of core developers have previously discussed this on the devel list - thus, dialogs should really be entirely declarative, with functionality living inside "widgets", which is also a necessity to end up with a reusable widget system, and one that can be maintained.
Like Thorsten said, anybody who's ever done any Nasal/Canvas coding would be in an excellent position to create widgets like those that he created.
However, I am pretty sure that manually porting our UI dialogs is going to be rather tedious process - i.e. look at some of the more complex dialogs that contain tons of Nasal functionality, these are already problematic in the sense that they are de-facto not purely declarative - in other words, while it may take an experienced contributor 10-20 hours to manually port a PUI/XML dialog to a different UI stack, a single aircraft developer who's ever done any moderate Nasal/Canvas coding, would be able to implement a few widgets in Canvas space, so that all dialogs using those widgets would automatically work "as is".
There's a list of PUI widgets and a matrix comparing that to what Canvas comes with: http://wiki.flightgear.org/Canvas_Widget_Matrix
You can also look at existing widgets: http://wiki.flightgear.org/Howto:Creati ... GUI_Widget
The shuttle stuff is cool, as is the E500 UI stuff, however to be truly useful, such work would have to be agnostic to the aircraft/use-case at hand, i.e. we would have to grow an actual library of widgets, ideally using README.gui as reference, i.e. to bring "our widget toolkit" up to par with the basic functionality that PUI has to offer.
While this may seem like a moot point given the Qt5/QQ effort, anything using the Canvas system would obviously also work for non-Qt builds, as well as for people wanting to use widgets for their avionics/MFDs