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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
