Hi, I have made a number of changes. I am not fully done yet, but I want to use this a a starting point for a discussion. My updated files are found at https://docs.google.com/folder/d/0B_4ZHt6ZZHE9ZTgycmQzcm9fVkk/edit
Here is in brief what I have done: 1. I have made a new class osgQt::WidgetAdapter. The purpose of it is to serve as a bridge between any QWidget (not only QGLWidget) and the QGraphicsWindowQt. All access to the context and the realization is handled through the interface of the WidgetAdapter. The actual implementation of the WidgetAdapter is done in its subclasses. So far, I have made only one subclass (for the QGLWidget), but the plan is to make one for the indirect viewing later on. The creation of the WidgetAdapteralso made it necessary to move some functionality into that class from the QGraphicsViewerQT, such as switching the context. 2. I have modified osgQt::GLWidget to inherit both the QGLWidget as well as the WidgetAdapter. Quite honestly, I do not want this double inheritance, and I would want it to inherit only osgQt::WidgetAdapter, and have a widget rather than being one. The delayed execution does however mandate the inheritance as the processDeferredEvents requires access to the QGLWidget::event() function. Hence, that still remains in the osgQt:: GLWidget. Also, I suspect that a lot of client code counts on osgQt:: GLWidget being a widget. All other event-handling (apart from the delayed one) is moved into the osgQt::WidgetAdapter, which gets the events through it's _receiver, and sends them to the graphics-adapter. I did not initially want the osgQt::WidgetAdapter::_receiver setup, but since osgQT::GLWidget inherits QGLWidget, I cannot let osgQt:: WidgetAdapter inherit QObject and receive the events directly. The example code works, my application (OpendTect) works. I do however have a couple of questions: 1. I never grasped the complexity of QGraphicsViewerQt::init, especially where we get the context from the traits, and gets the window, and then the osgQt::GLWidget from it (around line 550). It requires the QGraphicsViewerQt to have an getGLWidget just because of this, so I have reluctantly kept that function. 2. There were some context-handling that I did not fully grasp: In GraphicsWindowQt::makeCurrentImplementation() we did not check if the current context was identical to our context, while in GraphicsWindowQt:: runOperations() and swapBufferImplementation we did. I have kept this functionality with a bool on osgQt::WidgetAdapter:: makeCurrentImplementation, while I have feeling that this distinction is bogus, and the boolean argument can be dropped. 3. Who should own the Adapter? If it is a widget (as it is now with osgQt ::GLWidget), then it normally owned outside, while if it not a widget (which is what I want), then it would ideally inherit osg::Referenced. There are also a few more systematic changes I want to do on osgQt (which are not done yet). 1. On the CMakeList.txt level, I would want to have an option whether to use optimized Qt or not. We have both in our environment, and today it uses debug-qt with debug-osg and release-qt with release-osg. Most often we are not debugging qt, and it I'm thinking of an option: Use optimized qt. Default would still be what it is today. 2. I want to have support for global namespacing in Qt. Qt has support for always putting all Qt classes in a namespace, and we are planning on using that to avoid clashes between developers making plugins to our system and who want to use another Qt than we do. It would mean we make a set of macros that add the namespace in front of all Qt classes. Comments and suggestions are welcome! - Kristofer Tingdahl
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
