It is amazing to me how long you've used Producer, Robert, and not understood its architecture.
Yawn. Aboslutely I don't under anything about Producer.
Does this make me stoopid, if does this make Producer hard to understand, or does this simply mean that perhaps I do understand it and you've perceive me as not to understand Producer.
While allowing Producer::RenderSurface to be implemented on other windowing toolkits is awesome, it still doesn't solve the problem I mention above, you still need Producer to create the windows, be it FLTK one or an X11 one, you can't integrate a Camera into an app without RenderSurface or one of its subclasses.
The examples I give use the native platform to create windows. Producer does not create the windows. However, Camera does require a RenderSurface to fulfill its role in management of the graphics contexts, swaping buffers, etc.
Sorry mis-worded it slightly. Producer doens't have to create the windows. The essense of my point is the Camera can't live without a RenderSurface and this limits to how easily it ca be integrated with apps that already have graphics windows in place and don't wish to subclass from new versions of their graphics windows.
Consider the case where you already have an OpenGL application written and you want to add an OSG into the mix, this is the case where osgUtil::SceneView previously fullfilled the role of helping OSG integration. osgViewer::SimpleViewer fullfills this role, not needing any specific windowing support of any kind, but adds possibility of event handling and database paging over and above SceneView. Its this type of work that Producer isn't suited for.
Well, you're wrong about this, but it is pointless to try and prove it an email debate. The proof is in the pudding, as they say.
I've reviewed the examples, none of them do what I'm talking about, there adaption of the the base graphics window widget to RenderSurface. This is similar to the GraphicsWindow/GraphicsWindowQT3,GraphicsWindowFLTK approach, so I'm familiar with it.
However, its quite different from not requiring any subclassing for exisiting graphics window widget. The new OSG's osgsimple and osgkeyboardmouse examples take just this approach, they don't subclass anything, they just create windows and a view class and let the app do the event adaption and calling of frame. Its a fundamentally different approach.
Now this particular requirement of not requiring any subclassing is a niche requirement, not all users will want his approach, the new RenderSurface/GraphicsWindow style approach will suffice more, then the original RenderSurface being useful just fine the way it was for other users. There still remains these three seperate style of integration with end users application, Producer used just support the last class well, now it supports sets 2 and 3, but it doesn't support the first class.
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
