Hi Kristofer,
I can't remember the exact time I wrote the GraphicsWindowQt class, maybe
two or three years ago. I designed it along with the OpenThreads for Qt to
make OSG's threading and windowing APIs compatible with Qt so that to later
migrate to Symbian/Meego... But then iPhone and Android change the world
and the plan is deprecated. :-) But Qt integration is still a very
interesting and valuable topic nowadays and thanks to the contribution of
the whole community, the GraphicsWindowQt class is now usable for some
practical uses. I myself also use Qt in some client projects and think of
integrating OSG with QML as well as some Qt 5.0 new features (e.g., the
Qt3D module) some time later.
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?
Wang Rui
2012/11/8 Kristofer Tingdahl <kristofer.tingd...@dgbes.com>
>
>
> 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
>
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
