Hi Jeremy, Your re-design suggestions sounds reasonable. Rarely do first incarnations of code not require some re-factoring to get right. Often I find my first cut at a class/NodeKit useful as a learning experience as solution to a problem. The passage of development itself explores the problem domain so once you've been round the path once you know the route much better and know what elements to prune, what elements to expand upon, which short cuts are safe to take.
Over the next few months I should have a chance to dive and help out with your work on osgWidget, so feel free to direct me. I'm very sorry to hear about the the diagnosis of Leukemia, challenges in life don't get much tougher than having to deal with such an illness. Hopefully people's exploits with the code that you have generously written will give you good cheer, small comforts and amusements can sometimes brighten a day :-) The very best of luck with your therapy, Robert. On Mon, Feb 9, 2009 at 8:47 PM, Jeremy Moles <[email protected]> wrote: > On Thu, 2009-01-22 at 14:23 -0500, Jeremy Moles wrote: >> In osgWidget's current design, Widgets are notified of events such as >> mouseOver by a single ViewerEventHandler object that traverses a given >> root node and determines (or tries to :)) what kind of "thing" is going >> on. When I originally wrote this part of osgWidget, such was the limit >> of my knowldege... >> >> However, I would like to move to a more divorced system, in which each >> Drawable (Widget) or Node (Window) can use special UpdateCallback and >> NodeCallback objects so that they can simply "subscribe" to the events >> they're interested in. >> >> What I'm looking for are some ideas as to how I could best accomplish >> this. >> >> One possibility is that I could keep the osgWidget::ViewerEventHandlers >> that I currently have (MouseHandler, KeyboarHandler, etc.) except than >> instead of having them call the mouseOver methods on the Widgets >> directly they would simply set various state variables (mouse position, >> etc.) that the user could later query in their on NodeCallback or >> UpdateCallback functions. >> >> Does this make sense? Is this even a worthy endeavor? I get a lot of >> questions about how osgWidget "marries" the WindowManager+Event >> mechanism and the widgets it manages, so I'm looking for ways to break >> that up. The general idea is that I really want to use the OSG "update" >> traversal more, since right now I basically just have one object (the >> various ViewerEventHandlers) doing EVERYTHING on every object during >> their own update phase. > > I'm bumping this since it got no response really back in January. > > What I plan on doing now is something like this: > > - A Widget is no longer a Quad; a Widget is a pure virtual interface > that anything can derive from, including your existing Drawables (things > that can be picked). Quad (2D) and Cube (3D) will be the provided > implementations of workable Widgets. > > - There is no longer a WindowManager object. This will mean more work > on your part, but will make the library MUCH cleaner and OSG-like. In > the future I may provide a FocusGroup/FocusSwitch object that did what > the WindowManager object did. > > - There is no longer a Window object. Everything is a Widget that can > be added to everything else. This will be accomplished by requiring all > Widget objects (or your custom implementation) to provide a const > osg::BoundingBox& object that I will use to position one Widget in > relation to another using a clean API similar to the way World of > Warcraft does in it's GUI. > > - Each Widget will have an object it manages internally called a > WidgetEventState. SOMETHING will need to update this state in response > to mouse and keyboard events. By default, I will provide updater objects > in the form of GUIEventHandler implementations that will feed state data > to each Widget by processing normal OSG events. If you choose not to use > OSG events, you will need to write an SDL->osgWidget or GTK->osgWidget > or whatever you want conversion object. > > - As a result of the above, there are no longer a special Widget event > callback mechanisms; you will be required to use the normal OSG update() > convention and query the WidgetEventState object directly. This will > significantly reduce the complexity and confusion in osgWidget > currently. > > - All of the examples will be removed and condensed into one > osgwidgettest example. Making tons of examples is just a short term > excuse for me to NOT write documentation, so I need to stop that. > > ------------------------------------------------------------------------ > > I will post more on this thread as I go, but a lot is going to change in > osgWidget as the next months go by. I don't seem to have got the first > incarnation of osgWidget right (enough people aren't using it!) even > though my heart was in the right place. > > I'm smarter and wiser now, so hopefully Mk2 will be MUCH closer to what > osgWidget is supposed to be, although the version currently in OSG is > more than capable of doing anything you'd want. I don't think this puts > us in any danger for 2.8 release since there aren't enough people using > it, probably as a result of it's questionable API? :) Feel free to > remove it, Robert, if you feel that is necessary. > > ------------------------------------------------------------------------ > > Furthermore, I was diagnosed with Leukemia in the last month, so my > level of productivity won't be as high as I'd like, but it will be > sufficient. I need to get osgWidget to a point where it's easy enough to > understand so that other people can easily find bugs and fix them even > if my health does not permit me to do it personally. :) > > >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
