Hi all,
the following situation: I have a osgViewer::Viewer embedded into a
bigger GTK+ application. From a separate toolbar you can switch if the
mouse will modify the camera view (through the view's camera
manipulator) or if the mouse will modify objects within the displayed
scene (for now the mouse moves some marker object around). For the
layer development arbitrary many marker objects are planned.
So i have to limit gui event delivery to either the camera manipulator
or either the marker objects, which implement moving themselves around
using a node callback (a osgGA::GUIEventHandler subclass).
My approach now is to limit event delivery in some way. I used some
kind of callback (a libsigc++ signal) for this,which checks if a
(event,receiver) tuple is ok for delivery. the toolbar could than hook
into this signal.
So I added a signal to the osgViewer::Viewer subclass and added code
like
if(EventReceiverValidator*
erv=dynamic_cast<EventReceiverValidator>(&action_adapter))
if(!erv->isValid(event_adapter,object))
return false;
to my marker objects and to my camera manipulator.
this works,but i think it's ugly and hackish,also i cannot modify event
delivery to classes i did not write.
Is there a way to do this more elegant and in a more general way?
Because of the way GUIEventVisitor and GUIEventHandler work it seems at
least quite difficult to move the test to a custom
GUIEventVisitor which skips traversal as needed. Changing
GUIEventVisitor would also not help with camera manipulators. Moving
the test to a custom GUIEventHandler is possible but doesn't work on
classes which don't use the new event handler (like builtin osg
classes). A last,again quite hackish approach, would be a template
class like
template<class BaseEventVisitor>
class ValidatingEventVisitorAdapter: public BaseEventVisitor {
// overwrite handle(..) here
};
and using ValidatingEventVisitorAdapter<SomeVisitorClass> instead of
SomeVisitorClass everywhere, not very nice though.
thanks in advance, thomas
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
