Board index FlightGear Development Canvas

Widget.nas MVC & DefaultStyle.nas considerations

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Widget.nas MVC & DefaultStyle.nas considerations

Postby Hooray » Sun Jun 29, 2014 3:19 pm

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 :D

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Widget.nas MVC & DefaultStyle.nas considerations

Postby Philosopher » Sun Jun 29, 2014 3:38 pm

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! :D) 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.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: Widget.nas MVC & DefaultStyle.nas considerations

Postby Hooray » Sun Jun 29, 2014 3:48 pm

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: Widget.nas MVC & DefaultStyle.nas considerations

Postby TheTom » Mon Jun 30, 2014 12:08 pm

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.
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest