On 30 Jul 2012, at 13:31, Thomas Geymayer wrote:
> I have now pushed some updates to my branch. It is now possible to
> create windows (texture rectangles) with just using the property tree
> and place a canvas texture onto it.
>
> Mouse events are passed to the active window (=the window the cursor is
> hovering over, or for dragging the window where the drag gesture
> started) and can be handled from Nasal or anything else that has access
> to the property tree.
I'm going to let Stefan think about the GUI side, and I'll look at 2D panels,
since I've realised from the list below that the overlap is very large!
I'm not sure the focus policy you describe above is always going to work, but
it will certainly be sufficient for now.
>
> 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?
>
> - 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) Clipping:
> Already mentioned. At least rectangular regions are needed.
> (eg. group/clip-min[0..1], group/clip-max[0..1])
I need this for the 2D panels, will look at it.
>
> - (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...
>
> - 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.
>
> - Keyboard input:
> I haven't thought too much about it and also haven't done anything,
> but we will definitely need access to keyboard events :)
Panels don't need this, so I will ignore it for now :)
> - Own ideas:
> Come up with a new idea or something that I have already mentioned
> somewhere else :)
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.
>>
>
> The current window manager registers itself to the main viewer and
> subscribes on osgGA events, so the canvas has no dependencies on the old
> system.
Fantastic
>
> What do you think about the current way of handling mouse events? It's
> also just passing x/y and some more values to the property tree, but we
> need to forward the values somehow.
>
> Also I had to create a new event class (which uses most of the osgGA
> types) because the coordinates of the mouse where passed in the range
> [-1,1] which would make handling a bit more complicated...
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...
James
------------------------------------------------------------------------------
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
