Hi Robert,
you will need an #ifdef Qt4 thingy to replace:
Qt::WDestructiveClose with Qt::WA_DeleteOnClose
See http://doc.trolltech.com/4.0/qt.html
or http://doc.trolltech.com/4.0/qt.html#WidgetAttribute-enum
You could also replace the "USE_QT4" definitions with eg:
#if QT_VERSION >= QT_VERSION_CHECK(4,0,0)
#else
#endif
which will mean you could just point CMake at "a" Qt version
and avoid an extra compiler definition which is not needed.
This would also allow future checks for 4.4.0 and above which
introduce another 101 goodies that have been introduced since
4.3.x. The QT_VERSION and QT_VERSION_CHECK come with Qt.
Anyway I guess an OSG submission would be more useful to you
rather than more work for your plate ;)
Cheers,
Colin.
Robert Osfield wrote:
Hi Virgina,
I have compiled you on my system, compiling against QT4, and get the error:
/home/robert/OpenSceneGraph/examples/osgviewerQT/AdapterWidget.cpp:153:
error: 'WDestructiveClose' is not a member of 'Qt'
make[2]: ***
[examples/osgviewerQT/CMakeFiles/example_osgviewerQT.dir/AdapterWidget.o]
Error 1
make[1]: *** [examples/osgviewerQT/CMakeFiles/example_osgviewerQT.dir/all]
Error 2
make: *** [all] Error 2
I'm not very familiar with Qt so don't know the best way to map this
across to QT4. Suggesstions?
As a general note, when you have multiple views of a single scene
graph, the right tool to use is osgViewer::ComposteiViewer rather than
Viewer as otherwise you end up with duplicated update traversals and
out of sync frame stamps. Having things work event driven does
complicate things though, as CompositeViewer is designed around a
having single frame call that updates all windows at one time.
Supporting the event driven model with CompositeViewer/Viewer better
will something that we'll need to work on - this doesn't change the
crash issue, but it's something to bare in mind for the future.
Robert.
On Wed, Jul 2, 2008 at 6:59 PM, Virginia Holmstrom
<[EMAIL PROTECTED]> wrote:
Robert-
I have modified AdapterWidget.cpp from the osgviewerQt example. Use with Osg
2.4, Qt 3.3.3. It is obviously much simplified from what I have but exhibits a
similar problem.
What I changed:
1. Created 3 ViewerQts instead of just 1
2. Added a destructor to ViewerQt
3. Added the Qt::WDestructiveClose flag to the AdapterWidget, which triggers
the ViewerQt destructor to be called when the window is closed
How to use:
1. osgViewerQTd.exe cow.osg
2. Mine pops up cascaded, cow in each window
3. Close a window (middle window works well for me)
4. Check remaining windows, cow will likely have disappeard from one of them
5. If this didn't work, try closing the other windows, or running again and
closing the windows in a different order.
Thank you so much,
Virginia
Hi Virginia,
There is not much I can do without seeing the problem first hand. Is it
possible to recreate it by modifying the existing osgviewerQT example? If so,
could do this to effectively create a unit test for this particular usage case.
Another possible route with solving this type of usage case might be to
explicitly pass in the parent window when creating the graphics context, but
leave it to the OSG itself to create the windows rather that QT. I haven't
personally tried this, but it should be possible, even if it requires a few
tweaks to the OSG itself to enable it.
Robert.
On Wed, Jul 2, 2008 at 3:22 PM, Virginia Holmstrom <[EMAIL PROTECTED]> wrote:
Hello
I have been having problems with the destruction of my ViewerQT window and I
was wondering if anyone could shed some light on the issue. I am seeing
corruption in one view when another view is deleted (screen shot attached). We
are using OSG 2.4 and Qt 3.3.3 on WindowsXP and Linux. Problems are
reproducible on both platforms.
We are required to permit muliple views into the same scene, each in
its own window with its own navigation. The user may open one or more views,
close views at anytime, and open new ones. We have a set up similar to the
osgViewerQT example shipped with osg, where our ViewerQT inherits from both
osgViewer::Viewer and the AdapterWidget. We actually flipped the inheritance
order from the example, so that ours looks like this: ViewerQT : public
AdapterWidget, public osgViewer::Viewer due to compilation problems with the Qt
moc'ing the other way around.
Note we are using QGLWidget, not QOSGWidget, and we use multiple ViewerQts
instead of CompositeViewer due to problems discussed in thread
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2007-December/005676.html.
Hence our use of multiple ViewerQts is also similar to Enrique Parodi's
implementation he provided in that thread.
We store a ref_ptr to the root node of our scene external to the ViewerQts.
osg::ref_ptr < osg::Group > _osgScene; This ref_ptr persists as views
are opened and closed and is only released when the application closes. Each
time a ViewerQT is created we pass it the scene using setSceneData. All
ViewerQts get the same root scene node.
We started having a problem when we set the Qt::WDestructiveClose flag in our
AdapterWidget, which triggers the following destructors to be called in this
order on close:
ViewerQT
osgViewer::Viewer
osgViewer::View
osg::View
AdapterWidget
We normally perform cleanup of our own classes in ViewerQT::~ViewerQT,
however we see the corruption when the ViewerQT destructor is empty as
well! The AdapterWidget destructor contains
_gw->getEventQueue()->closeWindow();
The easiest way to reproduce the problem is to open multiple windows, then
close the first window(view), triggering its destruction. Frequently the last
window will be corrupted. I use corruption for lack of a better term. Geometry
may disappear, textures may disappear, osgText may become blocks, while other
parts of the scene are still visible in their original form. We've also had
problems with the background stars flipping to an opaque dome.
In the screen shot provided I closed the first window (hence blank space upper
left) and immediatly as I did that portions of the scene disappeard from the
last window (bottom right) and the text became blocks.
If I subsequently open a new window the scene usually appears normal.
I am not sure if I have a:
memory problem?
problem with the shared scene when ViewerQTs destruct?
problem in the GraphicsWindowEmbedded?
QT problem?
???
I am very open to suggestions. ;-)
Thank you so much,
Virginia
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
