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.
Am 2012-07-30 12:39, schrieb stefan riemens:
> Sounds like a fine plan to me, I was just wondering how you're
> planning to expose the events:
> - Copy values into properties
> - Expose the event class to nasal
>
> I'd vote for the first option... This would result in quite a lot of
> properties though, for all the possible states.
> I've been thinking about this, would it make sense to have a default
> mouse event handler, which exposes all "global"
> mouse state to some properties in (for example) /sim/mice/mouse[0]?
>
> That way, only a few mouse event values would need to be set as canvas
> properties.
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).
> On a different note: window management.
> I've seen that in Tom's private branch, he has started on a window
> class (albeit, it is just a skeleton currently).
> I think we indeed want a c++ window manager, which is basically just a
> dumb "visible thing that renders a texture".
> That way, the canvas code only has to render stuff to a texture and
> expose that, which is a nice abstraction point.
The "Window manager" just creates plain rectangles and forwards mouse
events. It also allows to modify window position and window size through
the property tree.
> So, given all that, where can I jump in to help? I must admit that I'm
> primarily interested in C++ development,
> rather than writing nasal ;(
Currently missing:
- 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).
- (Canvas Element) Clipping:
Already mentioned. At least rectangular regions are needed.
(eg. group/clip-min[0..1], group/clip-max[0..1])
- (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.
- 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.
- 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 :)
- Support multiple views/windows:
Currently the GUI can only be placed inside one view/window (see
Docs/README.multiscreen) but it would be nice to be able to move
windows between views.
- Own ideas:
Come up with a new idea or something that I have already mentioned
somewhere else :)
Am 2012-07-30 12:48, schrieb James Turner:
> Note that the canvas currently assumes render-to-texture, but for the
> GUI I'm not sure that's actually desirable - simply a separate camera
> per GUI window may be sufficient. Since the camera already arranges
> everything beneath the RTT camera this should be fairly minor change,
> if it's desirable.
It should probably event be enough to use just one single camera for all
windows. The big advantage we gain with render-to-texture is that by
using a larger texture we can get better anti-aliasing. For rendering
paths the stencil buffer is used so we only have pixel resolution which
can be seen at non horizontal or vertical lines or curves.
We could also use lazy rendering to only update the GUI texture if
something changes. Normally dialogs should be pretty much static...
> I need to spend some time on Mac release engineering, so I'm happy for
> you to work with Tom on 'window manager' - I'd suggest starting with
> the current GUICamera code, and especially the osgWidget base class.
> In particular my goal is to be able to kill off fg_os.hxx in the near
> future, i.e to have all events being passed into the canvas as osgGA
> types, not the old GLUT interface of raw x/y floats.
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.
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...
Regards,
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
