how can I replace the dialog with a canvas/nasal version?
Normally, you would have to manually port the dialog from PUI/XML to use Nasal/Canvas - the details are covered here:
http://wiki.flightgear.org/Howto:Creati ... ialog_filehttp://wiki.flightgear.org/Howto:Creati ... GUI_WidgetApart from that, there is an experimal (proof-of-concept) parser that parses a subset of PUI/XML and tries to automatically come up with an approximate/plausible version of the dialog by mapping PUI/XML layout/widget directives to the corresponding Canvas equivalents. A few days ago I posted a screenshot in another thread showing what the parser is creating when you ask it to render an unmodified version of map-canvas.xml:
http://wiki.flightgear.org/Howto:Proces ... ing_CanvasFor testing purposes I was using dialogs with lots of dynamic behavior, i.e. embedded Nasal stuff and update semantics implemented on top of properties and listeners, because that's the kind of stuff that Phi/Qt5 cannot easily support (as per Torsten's and James' comments) - but that's unfortunately how many of the most important dialogs tend to work, especially stuff like tutorials, checklists and the joystick UI tend to use tons of Nasal hacks.
I haven't really touched the parser since I originally prototyped it (roughly two years ago meanwhile) - that was all in response to the ongoing Qt5 debate on the devel list back then. Originally, it was about 300 lines of code - with comments and after restructing things a little, it's more like 500 LOC - but that's still fairly lightweight given that most dialogs are much more complex than that, and that even the embedded Nasal code is usually much more than that.
As can be seen, the parser is really just a minimal module, so it ignores many layouting/widget directives - however, anybody familiar with basic Nasal/Canvas concepts should be able to extend the parser easily to support their own dialogs/use-case. The idea here being that it should/would be less work to incrementally update/augment such a parser accordingly than manually creating new dialogs from scratch or porting the whole GUI from one toolkit to another.
The kind of skillset required to do either this would be roughly the same admittedly, but it should be much less work in comparison - especially if done step-by-step.
For instance, I am fairly familiar with Nasal and Canvas concepts myself, but I would not volunteer to port each and every dialog to use the Canvas system.
I found it more interesting to come up with a piece of code to do this semi-automatically
Maybe you could post a link to the actual dialog file so that we can take a look what is missing to make the parser convert the dialog to use a native Canvas ?