Looking at examples of some of our more sophisticated MFDs -like the Avidyne Entegra R9 or even just the Garmin GPSMap196- that may sooner or later benefit from being able to use native Canvas GUI widgets (buttons, checkbox, labels etc) with a custom style, it seems that we should strive to encapsulate event handling by not hard-coding things addEventListener() for mouse events or keyboard events at the Widget.nas level, because such devices may typically have their own "virtual" input means, such as a virtual keypad, or buttons/rockers to navigate between controls.
Using delegates for such events would allow us to reuse the same base classes regardless of the "front-end" in use - for instance, a MFD may be set up such that it doesn't respond to mouse/keyboard events, but we may still want to support highlighting the corresponding widget elements.
(As a compromise, we could see if explicitly setting events like "mouseenter/mouseleave" via setprop works well enough as a compromise)
The Avidyne Entegra R9 contains several examples where this kind of generalization would mean that the instrument could directly use a customized Canvas.Widget instead of their own hand-written widgets: https://gitorious.org/extra500/extra500 ... widget.nas - but obviously their widgets must remain functional even without the implicit assumption that widgets will always be controlled via keyboard/mouse.
If we could agree to eventually support this use-case, Canvas/avionics developers could also automatically help implement/extend and grow our widget library, which would obviously help related efforts, such as porting PUI, and we would be perfectly in line with ARINC 661
As an alternative, we could propvide an abstract base class/interface that encapsulates input handling which needs to be specifically implemented by each device, so that there are no mouse/keyboard-related assumptions at the Widget.nas level.