This now builds with cmake if added to the osg examples tree. A change to
examples/CMakeLists.txt is also required.
It is also possible to build this stand alone with qmake using the .pro file.
I think I've made the .pro sufficiently generic to build anywhere. The first
couple of lines in the file need to be adjusted for anyone's local environment.
This builds and runs on Linux and Win32 OK. See status section.
Mac has some problems. Qt was 4.4.2 and Mac OS X 10.5.2. 1) Had to adjust the
.pro file to hide QT_NO_DEBUG_OUTPUT or problems with a Frameworks header. 2)
Had to eliminate the outboard window to avoid a crash. 3) Only the lower-left
of the 4 views is OK. The other 3 views filled with frame buffer garbage. 4)
Maximize twice and we loose the lower-left too.
My colleague Liz Martin collaborated on the design and did the Qt work.
She is known for her copious comments. -- Don Leich, Intelligent Light
Linux/Win32 builds (on Mac substitute make for gmake):
gmake clean
qmake qosgwidget.pro
gmake
12/05/08 Status
---------------
o Implemented the skeleton of CompositeViewerQOSG and ViewQOSG (in
QOSGWidget.cpp)
o In testMainWin.ui, osgGraphicsArea is a "promoted" widget: It is promoted to
CompositeViewerQOSG
CompositeViewerQOSG inherits from both QWidget and osgViewer::CompositeViewer
o ViewQOSG inherits from QOSGWidget (which inherits from QWidget) and
osgViewer::View
o Bagged on allowing tab focus between the ViewQOSG widgets because:
o on resizing, OSG's CompositeViewer sets the camera (and view) focus to its
first osgViewer::View, which can create a disconnect between the Qt widget
(ie ViewQOSG) that has the focus and is receiving keyboard events, and the
actual ViewQOSG that the composite viewer acts on
o From empirical observation, it didn't seem to matter which ViewQOSG
received the keyboard event; the composite viewer applied the designated
action to the view the composite viewer consider current
o TAB focus would be given to a ViewQOSG even it had been completely
collapsed via QSplitter action in the QMainWindow. I was not successful
in my attempts to modify this behavior.
12/15/08 Status
---------------
o In this area, in testMainWin.ui, not only is osgGraphicsArea a promoted
widget (to CompositeViewerQOSG), but the 4 subviews are now also promoted
widgets, to ViewQOSG.
o I eliminated QOSGWidget::eventFilter().
o In QOSGWidget::QOSGWidget(), I no longer take x, y, width, and height from
the 'parent', I simply take it from itself.
Unfortunately, these changes don't help the Windows exe at all. Linux
continues to run just fine. But Windows doesn't see that TAB, and doesn't see
any *results* of the Key presses (Like 'l' to change lighting.)
5/15/09 Status
---------------
o Applied Martin Beckett's fix for WIN32 event queue handling.
5/19/09 Status
---------------
o Altered WIN32 event queue handling to not skip key events.
o Got Mac to build and sort of run. Qt is 4.4.2 and Mac OS X 10.5.2.
1) Had to adjust the .pro file to hide QT_NO_DEBUG_OUTPUT or problems with
a Frameworks header. 2) Had to eliminate the outboard window to
avoid a crash. 3) Only the lower-left of the 4 views is OK.
The other 3 views filled with frame buffer garbage. 4) Maximize
twice and we loose the lower-left too.
6/18/09 Status
---------------
o Simon Loic provided cmake infrastructure and help me debug some cmake
configuration problems. I needed to wipe my out-of-source object tree
and start over explicitly defining QT version 4, ala:
ccmake ../OpenSceneGraph-2.8.1 -DDESIRED_QT_VERSION=4
o Reimplemented QWidget::paintEngine to return 0 as recommended by doc.
This is purported to stop Qt from rendering anything in our windows.
o Eric Pouliquen recommended replacing setAttribute Qt::WA_PaintOnScreen
and Qt::WA_NoSystemBackground with Qt::WA_OpaquePaintEvent. Seems best
if we add Qt::WA_OpaquePaintEvent, get rid of Qt::WA_NoSystemBackground,
but keep Qt::WA_PaintOnScreen.
3cd0c50df3