Hi Robert, I have tried a few different 're-invent' paths with different ups and downs. We use qt 3.3.8 and osg 2.8.0, here is some of my experience.
QGLWidget provides functions like: grabFrameBuffer renderText a previous implementation of our software (with Producer) used these functions. So I subclassed from QGLWidget to keep this functionality. When creating a new traits with inheritedWindowData, on windows the event will not be form QT, but from windows itself. On Linux you will need to adapt the event (using an AdapterWidget). Unfortionately some graphics drivers had problems creating a valid context (Intel..). So I replaced the code using GraphicsWindowEmbedded and always using an AdapterWidget. Special attention was needed for scroll event and for modifier adaptation. For example scrolling in a treeview caused the viewer to zoom and a treeview to scroll simultaneously (only on widows, on linux the focus is stolen). It was nice to see your 'on demand' update scheme. For a viewer in a GUI it is not always very nice to be continously drawing. We also got some users with a single processor (which would be drawing with 100% cpu usage). So I made use of your new code. There are more little details/point of attention that are needed for the QT/OSG integration (how to setup multiple views/ shared context etc?). We currently use QT 3.3.8 and not 4.5, so our integration is 'out-dated'. But we do have the plan to start using 4.5 soon. I agree with your analysis of the situation and that it would be good to adress this issue. Our implementation currently suffices, but since i have some experience I am interested in this development. Have you seen David Guthries implementation (posted a few days ago), it uses windowsystemwrapper to integrate osg/qt? Have a good one, Rene Molenaar 2009/5/11 Robert Osfield <robert.osfi...@gmail.com> > 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 > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
