So this happens to be exactly what I've been struggling with over the past week. I want a multithreaded OsgViewer to integrate into a QT GUI and added into a QT layout.
I started with the osgviewerQT example and quickly learned that the embedded widget can't be multithreaded and that QOSGWidget/ViewerQOSG example doesn't attach to QT layouts/GUIs. I have not dove into the OsgViewer / GraphicsWindow code but it seems like others have gone down this road. What needs to be done to use an OsgViewer as a QT widget embedded into a larger GUI? I'd be happy to help in any work to generalize this type of integration. Thanks Scott On Mon, May 11, 2009 at 8:43 AM, Robert Osfield <[email protected]> wrote: > Hi All, > > There has been lots of support questions relating to Qt integration > with the OSG over the past year, and especially in the last few > months. This a good in terms of see a cross platform GUI toolkit > becoming more widely spread, bad in terms of the difficulties that > users still have. Part of the difficulties is down to Qt being a > little bit awkward to integrate with making it not entirely straight > forward, and while we have an example, it's just a guide so lots of > users are having to go re-invent the wheel each time. So it'd be good > to try and address this issue by providing a better Qt/OSG widget for > users to adopt directly. > > One of the design facets of osgViewer library is that it's designed to > work with multiple windowing toolkits, with four models of integration > possible: > > 1) GraphicsWindowEmbedded - provides very basic single threaded, > single context window integration suitable for use with simple apps > that use SDL/GLUT. > > 2) GraphicsWindow core osgViewer implementations (i.e. > GraphisWindowWin32/X11/Carbon/Cocoa) - full OpenGL + multi-context, > threadeding and pbuffer capabilities exposed. You'll find these > implementation interfaces in include/osgViewer/api/Win32, X11, Carbon > and Cocoa. > > 3) GraphicsWindow subclass (i.e GraphicsWindowWx) - 3rd party > implementation of a GraphicsWindow, potential for full capabilities if > all parts of GraphicsWindow are correctly implemented. For pbuffer > support one will have to add PixelBuffer implementation as well. > > 4) GraphicsWindow window inheritance - windowing toolkit provides the > window, while GraphicsWindowWin32/X11/Carbon/Cocoa provide the actual > OpenGL context implementation. > > > Now Item 1) is really just for very simple apps, and is often adopted > by end users because it's really easy to use, but almost always starts > limiting you as your project goes on. I wouldn't recommend 1 for > anything by GLUT/SDL style apps. > > Items 2 is great for sim and games that don't need any GUI. You can > get the full capabilities of the OSG with very little effort on your > part. If you want a traditional 2D GUI though then it won't help > you. > > Item 3 is possible, but rarely do 3rd party window toolkits do OpenGL > really well, often they won't expose the full capabilities of OpenGL > or support pbuffers. It also often requires the most work in > implementation. > > Item 4 is possible, but a little bit awkward, but potentially can give > users the best of both worlds - full OpenGL/OSG capabilities and the > 2D GUI. > > -- > > So where does that leave the Qt side? We'll my preference would be to > work together to get a GraphicsWindowQt and/or a window inheritance > implemented in a full and flexible way that users could just reuse the > implementation provided in a new include/osgViewer/api/Qt collection > of headers. I would suggest the implementation should be done > entirely in the headers to avoid the need for linking the osgViewer > library itself to Qt. > > Now I've tinkered with Qt, but I'm not Qt expert, to get a really good > implementation we'll need members of the community to pitch in with > helping refine the implementation. Anybody feel that they could help > spearhead this development? > > The first step might simple be to clean up the current Qt example, or > start a new example where the new classes could be refined and when > ready moved into their own directory in include/osgViewer/api/Qt. > > Thoughts? Volunteers? > > Robert. > _______________________________________________ > 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
