Re: [osg-users] osgWidget Design Though (Input Events)

2009-02-09 Thread Jeremy Moles
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

Re: [osg-users] osgWidget Design Though (Input Events)

2009-02-09 Thread Robert Osfield
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

Re: [osg-users] osgWidget Design Though (Input Events)

2009-01-25 Thread Sukender
Hi Jeremy, I don't know if this can be the ideal solution for you, but I can say what I did in my engine. I got both states class and event class. I guess events only are useful to osgWidgets, so I'll ignore states here (but they behave quite the same). All nodes that need to read/intercept

[osg-users] osgWidget Design Though (Input Events)

2009-01-22 Thread Jeremy Moles
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