Dear Wang,
I agree that the relationship of GraphicsWindowQt and GLWidget is > confusing. Other windowing interface like GraphicsWindowWin32 can either > create its new window or accept an existing one for the rendering context > use. An ideal result in my opinion is that we can directly set a QGLWidget > as an OSG window using Traits::inheritedWindowData, but the event handling > must be overrode, for example, using installEventFilter() to make sure OSG > can communicate with Qt window. In this way maybe we will not have to use > any adapters but only send a QGLWidget pointer to the traits like: > > osg::ref_ptr<osg::Referenced> windata = new > osgQt::GraphicsWindowQt::WindowData(qtWidget); > traits->inheritedWindowData = windata; > osg::GraphicsContext* gc = > osg::GraphicsContext::createGraphicsContext(traits.get()); > > And thus remove present GLWidget class and provides a clear solution to Qt > developers. What do you think about that? > This is a similar idea to what we have right now, so I am in favor of it. In the proposed code, the WidgetAdapter handles all events to from the widget by installEventFilter. In your proposal there is essentially a merge between my WidgetAdapter and osgQt::GraphicsWindowQt::WindowData. The only thing I would want to add would be to make WindowData a virtual class, with specific implementations in the subclasses (i.e. one for use with the QGLWidget and one for indirect viewing with the QWidget (or QBitmap)). The only worry I have, and I cannot judge the implications, is that there seems to be a workaround of the QGLWidget's events, where there are events that are delayed and processed later. If this workaround is needed, then there are no other options than to inherit QGLWidget. Given this, a possible update of my proposal would be: 1. Merge the WidgetAdapter into the GraphicsWindowQt::WindowData. This class would handle the normal events from Qt to OSG (through an installEventFilter) and also provide the interface for GraphicsWindowQt to control the Qt part. 2. Create a quite thin osgQt::GLWidget class that only handles the delayed events. 3. Make a osgQt::GLWidgetAdapter that inherits GraphicsWindowQt::WindowData and can be constructed with a osgQt::GLWidget. Then later, once the infrastructure is in place, I may then create other subclasses of GraphicsWindowQt::WindowData for my indirect viewer. Any comment on such an updated proposal is welcome (before I start coding). One question I have is (as being new to OSG), is how much respect (or not) should be given to the current interface. If we change too much, then all application developers would have to adapt their code. This may be minimized by retaining the old interfaces and fixing things under the hood, but depending on the extent of the redesign that may or may not be possible. Best regards, Kristofer Tingdahl
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
