I don't remember the details, but I think there /is/ some way to disable event handling per Canvas - for instance, tooltips (which are Canvas based) don't handle any events (I think) - so that's where I'd suggest to look.
Apart from that, the restriction itself is there and has been there since day 1 - we were considering to improve things a little originally, but then everybody on the devel list and their dog went crazy about phasing out PUI in favor of using Qt5 for the aircraft center (launcher) and the built-in UI, so that we stopped working out a better scheme, considering any work in that area unnecessary.
Since then, it seems that things have stalled a little in the whole Qt5/GUI department - mainly because the whole effort of porting the built-in PUI based UI to Qt5 seems to have been massively undererstimated by the people involved in the Qt5 effort, but also due to architectural/threading issues that bugman mentioned repeatedly could become a problem somewhere down the road.
The thing to keep in mind here is that the original core developer consensus required all Qt5 work to remain entirely optional and constrained to a single module only, which means that we'd still need some kind of "fallback" for the non-Qt5 use-case, and that tons of work would go into converting existing functionaltiy using an optional dependency, i.e. ultimately an optional feature.
The nitty-gritty details of the whole PUI vs. Qt5 vs. Canvas UI can be found here:
http://wiki.flightgear.org/Howto:Proces ... ing_CanvasThis includes an experimental prototype of a pui2canvas parser that translates a subset of PUI/XML to the corresponding Canvas equivalents to approximate a subset of the PUI/XML ui. All of this was originally prototyped during a single weekend using roughly 300 LOC (Nasal only, no C++ changes needed), and meanwhile it's roughly twice that I assume.
This was never intended to "compete" or "conflict" with the Qt5 UI, it was merely intended to be a simple fallback that would allow us to get rid of PUI without causing tons of work - especially looking at some of the more complex PUI/XML dialogs that use tons of embedded Nasal code (think tutorials, joystick ui, checklists etc) - realistically, none of these can just be "ported" to a different UI framework like Qt5, unless a parser-based approach is used, that would also support Nasal scripting.
Thus, someone offering to rewrite the built-in UI using a different toolkit like Qt5 (which, again, is required to remain entirely optional) and witout using a parser supporting Nasal, would automatically volunteer to handle just that: re-implementing tons of PUI dialogs that contain useful features that we accumulated over the course of almost 2 decades
Realistically, that ain't happening any time soon for obvious reasons.