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
