Am 2012-07-31 10:00, schrieb James Turner:
>> Currently I'm copying all values to the property tree. The following
>> properties are set on the canvas of the active window:
>>
>> mouse/x
>> mouse/y
>> mouse/dx
>> mouse/dy
>> mouse/button
>> mouse/state
>> mouse/mod
>> mouse/scroll
>> mouse/event
>>
>> I don't know if it would give as any advantages to have some global
>> mouse states because the values are only valid for one single window
>> (coordinates are relative to window origin).
>
> Hmm, I was hoping we'd be able to register callbacks on specific widgets (or
> panel nodes in my case) - do you have a Nasal layer on top of these
> properties to forward semantic events ('left button press', 'scroll up',
> 'double-click') to Canvas elements?
mouse/event contains the type of event (its a
osgGA::GUIEventAdapter::EventType) and is always updated last, so it is
enough to just register a callback on mouse/event and read all the other
properties.
The advantage of just using properties is that you can easily create
mouse events from different sources, even from Nasal (eg. to control the
cursor inside a MFD also with keys or the joystick one would just need
to write to the according properties and to the canvas it looks just
like any other mouse event).
>> - Window Stacking:
>> New windows always appear on top of older windows. It would be nice
>> to have the possibility to change stacking order (either reorder
>> the windows or use z-buffer with different z-values)
>>
>> The window manager could eg. listen on a special signal property on
>> each window (eg. /sim/gui/canvas/window[i]/raise) which moves the
>> according window to the top of the current window stack.
>>
>> I'd prefer window reordering because it would make checking for a
>> window at a given position very ease, because we'd just have to
>> check for the first match in revers stacking order (from topmost to
>> lowest window).
>
> Have either of you thought about implementing the menubar? Which in PUI is a
> series of popup-windows, just wondering if the 'window manager' needs to be
> aware of such windows in terms of z-ordering.
>> - (Canvas Element) Picking:
>> Forward mouse events to canvas elements (trigger onhover, onclick,
>> etc.)
>> The canvas could listen for creation of the signal properties and
>> then add the according region to a list of monitored regions. If
>> the cursor is in one of the regions the property is signaled.
>
> Ah ok - can you explain more how you see this working? I'd imagined passing
> a Nasal function as a callback into the element:
>
> element.setHoverCallback( fun = { .... } )
> element.setClickCallback
> element.setWheelCallback
>
> and so on...
I was thinking exactly the same. the setXxxCallback functions would just
add a listener to mouse/event, and upon change read all values into a
hash and call the registered function.
>>
>> - Use images inside Canvas:
>> We need a new element type to also display images and other textures
>> (eg. also the texture of another canvas) inside a canvas. Not
>> everything can easily be represented using just vector graphics, so
>> images will also be needed.
>
> Right, the 2D panels are just textures. I will also add a 'scale 9' (aka CSS
> border image) element since my impression is this would be very useful in
> styling GUI elements.
Sounds useful. Maybe we can do also an element which supports this for
vector images (eg. for buttons, inputboxes, etc.)
> One thing I want to fix for 2D panels, the GUI and 3D picking is cursor
> feedback. So if a 3D model or 2D 'knob' is clickable, we can show a
> hand-cursor and a tooltip on hover. This would be a *huge* usability win for
> people learning new cockpits, besides the GUI. Unfortunately OSG cursor
> support is somewhat limited.
With osgGA handling mouse over events is now also possible. So for
canvas elements adding tooltips is very easy. For 3D picking we would
need to forward the mouse intersection to Nasal. This will also be
needed for interacting with canvases placed on 3D surfaces.
> Personally I'd like an event class exposed to Nasal (I can do that part, lots
> of experience with it now!), which is available in the callback functions I
> suggested above: so in a hover / wheel / click callback, one has an 'event'
> object with:
>
> event.button (button that triggered the event)
> event.type (press / release / click / double-click)
> event.time (maybe...)
> event.buttons (state of all the mouse buttons)
> event.modifiers
> event.x, event.y
> event.globalX, event.globalY? (do we need these?)
>
> And this can potentially have some helper functions to transform X/Y
> coordinates or even find the lat/lon of the scene location...
Looks like a good idea (relative changes would also be useful eg. for
dragging). The question is only if we need to expose this class from C++
or if it is enough to build it in Nasal.
Tom
--
Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org
------------------------------------------------------------------------
Student of Computer Science @ Graz University of Technology
------------------------------- Austria --------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
