Mouse handling and callbacks?

[omega95]

Woohoo! I got it working, now to create a GUI FMC Interface.



Btw, is there a tutorial on importing SVG images into the GUI? What about NON-svg images? I mean png, would that work? And is there a way to make things on the canvas clickable? Well, you click it and it does something? If not, implementing that might be a good idea...

Probably say, if object is the name of the child object, then you specify the function like:

Code: Select all

var PickAnimation = {

    "buttons": [0, 1],
    "repeatable": 1, # Or Boolean True
    "bindings": [{
        "command": "nasal",
        "script": "<nasal script here>"
        },
        {
        "command": "property-toggle",
        "property": "/path/to/property"
        }]
}

object.setPickAnimation(PickAnimation);


And probably for quick 0 button click reference,

Code: Select all

object.setClickFunction(func() {

    #The function to be executed when clicked goes here

})

Hope you'll consider my suggestion, thanks a lot!

[Hooray]

• FMC interface: I'd try to use a layered design here, so that there's a shared layer for your GUI and cockpit panel interface, we talked about the details on the wiki. It's really only about linking properties either to GUI widgets or to cockpit hot spots. Ideally, you should be able to use the same code to load/display your FMC onto a GUI widget, and then just link the events to buttons/checkboxes etc.
• SVG usage is documented in the wiki - there's a "tutorials" section in the sidebar, please see: http://wiki.flightgear.org/Howto:Use_SV ... e_a_Canvas (see svg.nas for further info)
• non-vector images like png are currently not yet supported unfortunately, but support is definitely planned and as far as I understand, currently being worked on by James (Zakalawe), because he's working on porting the 2D panel system over to the canvas, according to the devel list.
• clickable canvas regions: yes, that's currently being worked on, please see the wiki: http://wiki.flightgear.org/Canvas_Widge ... ks_Pending

As you can see, "clickable" canvas elements are implemented via conventional property listeners, which are registered to a bunch of canvas-specific child nodes:

mouse/x
mouse/y
mouse/dx
mouse/dy
mouse/button
mouse/state
mouse/mod
mouse/scroll
mouse/event

You can probably see, how powerful and simple this concept really is.

I'd suggest to play around with it and inspect the canvas texture via the property tree browser, you'll quickly see how this works then.

[omega95]

As you can see, "clickable" canvas elements are implemented via conventional property listeners, which are registered to a bunch of canvas-specific child nodes:

mouse/x
mouse/y
mouse/dx
mouse/dy
mouse/button
mouse/state
mouse/mod
mouse/scroll
mouse/event

You can probably see, how powerful and simple this concept really is.

Hmm, I just understood that, if a nasal api for click-ability hasn't already written, may I start working on it? I don't want to disturb Tom from what he's currently working on and I think I've figured out how to make a simple click button handler (like in the wiki), but then if this is already being worked on, I guess I should just leave it alone.

[Hooray]

Read again
The Nasal API works such that you can simply register conventional Nasal listeners and callbacks, to receive events for certain canvas elements.
No need for any fancy mouse handling.

Basically, it'll work like this:

• create a group
• add child elements
• enable picking for the elements
• you'll automatically get notifications, i.e. "events" in a sub tree of the group/child
• register listeners to these properties
• invoke your own callbacks automatically

In pseudo code, it will be as simple as this:

Code: Select all

var scroll_bar = scroll.createChild("path")
                                             .moveTo(764,2)
                                             .vert(100)
                                             .setStrokeLineWidth(4)
                                             .setColor(0.94, 0.47, 0.27)
                                             .setHandler( func { print("GUI event!"); } );


The "setHandler" method would then just register a listener via _setlistener() for its own group/child region.

[omega95]

Read again
The Nasal API works such that you can simply register conventional Nasal listeners and callbacks, to receive events for certain canvas elements.
No need for any fancy mouse handling.

Basically, it'll work like this:

• create a group
• add child elements
• enable picking for the elements
• you'll automatically get notifications, i.e. "events" in a sub tree of the group/child
• register listeners to these properties
• invoke your own callbacks automatically

In pseudo code, it will be as simple as this:

Code: Select all

var scroll_bar = scroll.createChild("path")
                                             .moveTo(764,2)
                                             .vert(100)
                                             .setStrokeLineWidth(4)
                                             .setColor(0.94, 0.47, 0.27)
                                             .setHandler( func { print("GUI event!"); } );


The "setHandler" method would then just register a listener via _setlistener() for its own group/child region.

I didn't really understand that, where do you specify the event?

Other than that, is it possible to load canvas INTO 2D panel? Not using 2D panels in canvas...

[Hooray]

Hmm, I just understood that, if a nasal api for click-ability hasn't already written, may I start working on it?

I'd suggest to get in touch with Tom, but it is my understanding that there's no need for any fancy API here, because the system is already extremely flexible and powerful as is. And if you really wanted to make this even simpler, then it's really all about adding a bunch of *methods* to the api.nas file, so that method chaining works properly here.

Keep in mind that mouse-handling will not be GUI-specific, it will just as well be required by most instruments, and especially "touchscreen"-style devices. Thus, this needs to be done at the C++ level, and merely exposed via the property tree to Nasal.

Once you fully understand how this will work, you'll see that it's really powerful - and even the API that you outlined previously, would be inferior to the current system.

I didn't really understand that, where do you specify the event?

That's just pseudo code, you have a bunch of events in the form of PROPERTIES, properties that are specific to each canvas window/widget, so you can directly register listeners and invoke your callback: once a callback is invoked, you'll know for sure that its associated "event property" was triggered previously.

Other than that, is it possible to load canvas INTO 2D panel? Not using 2D panels in canvas...

Yes, that should be possible - it's really all about specifying a placeholder in XML space (i.e. object name/texture name) and then dynamically replacing the texture via the placement method.

[omega95]

That's just pseudo code, you have a bunch of events in the form of PROPERTIES, properties that are specific to each canvas window/widget, so you can directly register listeners and invoke your callback: once a callback is invoked, you'll know for sure that its associated "event property" was triggered previously.

That's exactly what I wanted to do...

[Hooray]

Do you now fully understand how this is working? Otherwise, maybe Tom can explain this a little better, after all he's written all that code!

[TheTom]

Currently mouse events are exposed to Nasal by writing to the already mentioned properties inside the canvas. This however will be replaced by extending the core to allow registering event listeners to canvas elements which will get passed an event object containing all the relevant information (James is currently working on this and wanted to push something the next days).

I'm currently working on picking, so that you can simply add a listener to the element you want to receive certain events and the rest will be handled automatically.

If you use the handlers like I do in the example it will be very easy to use it with the upcoming event system. You just need one listener attached to "mouse/event" as it is updated always after all other mouse properties.