[osg-users] CompositeViewer, GUIEventHandler::handle() and events cascading across Views

134 views
Skip to first unread message

Andreas Stahl

unread,
Dec 4, 2012, 12:14:26 PM12/4/12
to osg-...@lists.openscenegraph.org
Hello,

there's an aspect to the compositeViewer that I don't think I quite understand. First I'd like to explain what I want to achieve:

I want to create a user interface that consists of one big hud, that contains different viewports on the scene, and if the user clicks somewhere a picking event is dispatched, identifying the node (hud or scene) that was picked and choosing a handler accordingly. I know how I could create one big scenegraph with multiple cameras and different viewports and render orders, but since this will be rather dynamic and user customizable, I want to keep concerns separated as neatly as possible.

To achieve that, I would rather like to use one (or multiple) view(s) to represent the "scene layer" and another to hold the hud/gui-layer, each with its own and distinct scene graph. So I create two views with the same viewport, Main and HUD, and hook up a simple GUIEventHandler subclass handling the picking in each view. I set both views to accept focus events. In the handle method I return true when an object of the corresponding graph was hit, false if not.

Now, what I would expect from other GUI toolkits that returning false from a handler indicated that the event was indeed not handled in the first receiving view and should be propagated to the next views that contain the event's x and y, and conversely returning true should abort this cascade.
This does not happen, however. The event is sent only to one of the handlers*, so I looked in CompositeViewer::eventTraversal and saw that the return values of handleWithCheckAgainstIgnoreHandledEventsMask are actually not used in determining if a cascade should happen or not.

So I have two questions:

1. Is using CompositeViewer with overlapping views actually a sane way to tackle this, or should I just go the single-view route described in the first paragraph?
2. Are there plans to support event cascading in overlapping views for future releases? If not, what is the significance of the bool return value of handle?

Also, if you would be so kind, if there's some fundamental misunderstanding on my part, I hope you can point it out.

Thank you!

Holiday Cheers,
Andreas


*) which instance of the handlers is chosen appearently is determined by the order in which the cameras' setGraphicsContext is called. The last one called receives the event, independent of view or render order.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51350#51350





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Andreas Stahl

unread,
Dec 10, 2012, 6:59:06 AM12/10/12
to osg-...@lists.openscenegraph.org
So I went ahead and tried to rework the problem as one big scene graph and multiple cameras into it. I might get it to work, but a more flexible event handling between overlapping views could have really helped. Maybe I'll give subclassing CompositeViewer a shot, overriding eventtraversal.

One question then still stands however: What is the significance of the return value of osgGA::GUIEventAdapter::handle and when should it return true?

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51492#51492

Robert Osfield

unread,
Dec 11, 2012, 5:30:41 AM12/11/12
to osg-...@lists.openscenegraph.org
Hi Andreas,

On 10 December 2012 11:59, Andreas Stahl <andrea...@tu-dresden.de> wrote:
So I went ahead and tried to rework the problem as one big scene graph and multiple cameras into it. I might get it to work, but a more flexible event handling between overlapping views could have really helped. Maybe I'll give subclassing CompositeViewer a shot, overriding eventtraversal.

If the default behaviour is not what you want then overriding the eventTraversal method would be appropriate - it's why the method is virtual :-)
 

One question then still stands however: What is the significance of the return value of osgGA::GUIEventAdapter::handle and when should it return true?

The event handler handle() method should return true if the event is handled, but it's also the event handlers responsibility to decide whether it should handle already handled events.  Some event handlers don't want to handle already handled events, which other need to handle all events regardless of whether another event handlers has handled it already - examples of this would be a resize or frame event.  Have a look through the various event handler handle(..) implementation in the OSG code base to see which event handlers do what.

Robert.
Reply all
Reply to author
Forward
0 new messages