Widget.nas MVC & DefaultStyle.nas considerations

[Hooray]

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.

[Philosopher]

I think for key-based navigation the mouse events could simply be disabled and their actual effects exposed – e.g. "hovering" becomes "soft-selected". As Canvas window support also starts capturing keyboard events (hint! ) the same approach could be used.

For example, hovering is handled in Widget.nas currently and is exposed as a simple member: https://gitorious.org/fg/fgdata/source/ ... s#L145-158. We could manually set this member on our own, in response to key events, or expose a API like "setSoftSelect(selected=1)" to do this. (The advantage of an API is that for widgets like lists, where only one element should be soft-selected at a time, the function could be easily overridden to keep track of that – deselect current one and select this one instead.) Then the widget would be updated/re-rendered and the change would show up.

[Hooray]

Agreed regarding exposed effects - maybe we need some kind of WidgetState that encapsulates this so that each kind of front-end/placement can decide how to respond to certain events depending on the control/interaction means. We need to keep in mind use-cases like Gijs' ND/PFD which support a Canvas GUI dialog viewing mode, and that one could optionally respond to standard mouse/keyboard events (if so desired). This applies even more so to F-JJTH's GPSMap196 which uses a Canvas skin with buttons and switches.

[TheTom]

What is the problem with the current design? If there is no mouse or keyboard you have to simulte it somehow. You can just send the according mouse or keyboard events created by whatever interaction method you use (Although it is not yet possible to create MouseEvents from Nasal).
Also, on the second level of abstraction, nearly every widget provides methods to change its state. eg. Button.setChecked/setDown/toggle or ScrollArea.scrollBy.