HI Jeremy, On Mon, Nov 24, 2008 at 8:54 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote: > Hello all! Allow me to talk briefly about osgWidget's current design and > perhaps how I can change it for the better.
I'm afraid I have yet played with osgWidget enough to give a definitive answer about WindowManger yet. I am working towards diving into osgWidget, my inbox just is so full... but I'm getting there... just slowly. I can throw a few general comments. I'm a strong believer in loosely coupled highly cohesive design, and the ability to add functionality to an scene graph application by just adding subgraphs into the scene graph without need for lots of high level refactoring of the application to add that functionality. A good NodeKit's will embody this - so if you add particle system to your model file and then load it you application suddenly can do particles systems, if you decorate the scene with a shadow node then it'll be shadowed. With osgWidget one of the tasks is moving the events, and in particular mouse events, from screen space into the local coordinate system of the widgets. The OSG has support for an event traversal so an event callback gets events from the viewer, and this traversal also provides an ability to grab the current View, which does give you the ability to then find out the camera that is currently active in the viewer that sits above the scene graph. View::computeIntersections() does this camera selection for you. The IntersectionVisitor will also cope with internal Camera's in the parent chain (or a least since I checked in bugs fixes for it ;-). For the osgvnc, osgbrowser examples I introduced an osgView::InteractiveImageHandler (even callback) that does this conversion of the mouse pointer all done by using the osgViewer::View, but acquiring this from the event visitor, rather than requiring the callback itself to know about the view. This means that you can add the event handler to the drawable of interest and then getting events to it, use the View* provided by the event traversal, to compute the intersection and the reproject the coords, all without the handler or the geometry it's attach ever know explicitly about the View. This is an example of a loosely coupled yet highly cohesive design in action. Reviewing WindowManager in svn/trunk I see that it takes a pointer to the view in its constructor, then keeps around this pointer. This breaks the loosely coupled requirement, as it links the subgraph with the viewer, something that can only be done in application code. However, it wouldn't take much to refactor WindowManger so that it had a traverse methods that captured event traversals and then dynamically checked for the osgViewer::View. This would free up the WindowManager so that it would act just as a decorator for a widget subgraph, and could become a node that you could happily serialize in and out without the need for hardwiring into the application code. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
