Hi Loic, Thanks for the link. I've done a quick review of the implementation. In terms of osgViewer it is certainly a step above where the osgviewerQT example w.r.t WindowSystemInterface. The use of QGLWidget does limit one a bit though, and the way the QGLWidget is set is rather simplistic as ignores practically all of the settings in the Traits.
Personally I'd favor an Qt implementation that use graphics window inheritance to get a full featured GraphicsWindow as a Qt widget. For Qt users I think there needs to be integration done in Qt terms as well, for instance having a OSGWidget that you can add to your application. Another side topic is do you have a window/widget that owns a viewer/composite viewer, or go for window/widget that owns just the GraphicsWindow, and the viewer is owned by the application in the traditional way that the OSG is used. There are reasons to use both approaches, the later being the most flexible. Robert. On Mon, May 18, 2009 at 3:34 PM, Simon Loic <[email protected]> wrote: > Hi Robert, > About David Guthries implementation, it was indeed posted on the osg-users > ml. > Here is a link to this thread : > http://forum.openscenegraph.org/viewtopic.php?p=11636#11636 > Cheers, > Loïc > > On Mon, May 18, 2009 at 4:03 PM, Robert Osfield <[email protected]> > wrote: >> >> Hi All, >> >> I'm mainly just tracking this thread trying to get a feel for what's >> working an what's not, and who might be able to help refine the right >> approach. So for nothing concrete has jumped out.. >> >> 2009/5/13 René Molenaar <[email protected]>: >> > Have you seen David Guthries implementation (posted a few days ago), it >> > uses >> > windowsystemwrapper to integrate osg/qt? >> >> No I haven't, was this posted on osg-users? Did I miss it spinning >> past a 100 knots? >> >> I don't know if it's related, but one design aspect to osgViewer which >> was built in front the start is the >> osg::GraphicsContext::WindowSystemInterface which provides the >> abstraction away from the implementation. This interface class was >> the potential of having multiple implementations, and for the >> implementations to be moved out into plugins, just like we have >> plugins for databases and wrappers right now. >> >> For ease of building and running OSG apps I didn't go for the full >> plugin approach from WindowSystemInterface, rather allowed >> implementations from X11, Win32, Carbon and Cocoa to be imbeded >> directly into the osgViewer. This means you only have to link against >> osgViewer to get a viewer up on the screen, but it does mean that the >> library itself isn't as flexible w.r.t dynamically loading the >> implementations. It wouldn't be a great deal of work to do this >> though. Or perhaps we could still have the inbuilt implementations, >> but allow plugins to add extra ones. >> >> A plugin for Qt support would certainly be possible. Potentially one >> could even compile the core osgViewer library without any default >> implementation and rely on such a plugin, or change the default >> implementation that one compiles against. >> >> Robert. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > -- > Loïc Simon > > _______________________________________________ > 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
