Getting Qt linked in DGL

Question:
In DGL, more precisely the file DGLWindow.cpp, we modified the create() function and replaced it with a Qt implemention.
We have included other header files such as . So as needed we modified the header file accordingly. As you told us in your last mail, we will need to rebuild everything.

Usually to build and run a Qt applications we used to do these commands:

> qmake -project
> qmake
> make
> ./qt_application

What should we do to build the DGLWindow.cpp (with the Qt implementation). Should we change the Makefile or other files such as Makefile.am/Makefile.in.

Apparently the Makefile is generated by the "configure" command in the root directory of DGL. Should we change anything in the configure file?

=================================================================
Answer:
To get Qt linked in, you'll need to mess with the cmake configure files.
This is a bit of a project.

You'll find the file CMakeLists.txt in many directories. These files define
what cmake will use and where it'll look to find stuff.

This command will tell me the files that contain the word "producer":

> find . -name CMakeLists.txt | xargs grep -i producer | sed -e 's/:.*$//' | uniq
./dgl/DSOs/dgl/CMakeLists.txt
./dgl/DSOs/dosg/CMakeLists.txt
./dgl/programs/dgl/dgl-readSta

te/CMakeLists.txt
./dgl/programs/dgl/dgl-waitExec/CMakeLists.txt
./dgl/programs/dgl/dgl-navControl/CMakeLists.txt
./dgl/programs/dosg/dosg-bounds/CMakeLists.txt
./dgl/programs/dosg/dosg-fly/CMakeLists.txt
./dgl/programs/dosg/dosg-transform/CMakeLists.txt
./dgl/programs/dcoin/dcoin-fly/CMakeLists.txt
./dgl/lib/dgl/CMakeLists.txt
./dgl/lib/dosg/CMakeLists.txt
./dgl/lib/dcoin/CMakeLists.txt
./dgl/lib/dvtk/CMakeLists.txt
./dgl/CMakeLists.txt
./dgl/examples/CCallbackHelix/CMakeLists.txt
./dgl/examples/quad/CMakeLists.txt
./dgl/examples/dosgfly/CMakeLists.txt
./dgl/examples/coinload/CMakeLists.txt

This isn't as bad as it looks. dgl/CMakeLists.txt is probably where you
should start, as it defines how to find Producer. The rest should just use
it, and the changes should be fairly mechanical.

In dgl/CMakeLists.txt, look for Producer. Most of the heavy lifting is from
lines 208-263. The first part tells cmake a name to look for, "Producer",
"Producerd" if running Windows, and a series of directories to look at to
find it, both the library and the include files. It looks in a mixture of
environment variables and hard-coded paths. If Qt has some environment
variables that tell the system where to find its library and include files,
just use those. If Qt has a program you can run to find out this
information (like fltk does, later in the file) just use this.

Later in the file, lines 306 & 404, Producer is added to the OSG & VTK
list of include files. You can add Qt there instead.

In other CMakeLists.txt files, the Producer include file and library are
added to the compiler flags, so just replace them with the Qt equivalents.

After you change the CMakeLists.txt files, rerun cmake to generate new
Makefiles.

Multithreading in DGLWindow.cpp

#ifdef _X11_IMPLEMENTATION
if (DGL::getApp()­>getMultiThreaded())
RenderSurface::initThreads();
#endif
#ifndef WIN32
if (!DGL::getApp()­>getMultiThreaded())
m_surface­>useConfigEventThread(false);
#endif

This appears to be related to threading, and what to do if you're running
multi-threaded. I think for now you shouldn't worry about threading, and
just comment it out. We can deal with it later, as Qt does its own
threading. You might want to make single threading the default by changing
DGL.cpp, line 39, from

bool DGL::m_multiThreaded = true;

to

bool DGL::m_multiThreaded = false;

and this way all the multi-threading code will be automatically skipped.

VisualChooser in DGLWindow.cpp

As near as I can tell, the VisualChooser is just a class where you set the
attrbutes of RenderSurface. It's used by Producer.

I see that DGLWindow is creating a VisualChooser and setting its attributes.
Later in the code it creates a new RenderSurface and assigns the
VisualChooser to it:

m_surface->setVisualChooser(m

_chooser);

Later it's used in the ralize() method, which actually creates the window.

m_surface->realize(m_chooser,
m_parentWindow->getRenderSurface()->getGLContext());

The code for that is specific to each platform- Window, X11, OS X. In the
X11 code, if the chooser isn't passed it uses the one you set it too
earlier.

Anyway, just think of it as a class that stores attributes of a window.

Modify a DGL program

If you wish to change the DGL program, you pretty much need to change the
code and rebuild.

The good news is that you don't have to rebuild everything if you just change
a class implementation or DSO.

For example, if you change DGLWindow.cpp, all you need to do is to cd to the
directory it's in and type "make install".

If you change an include file you pretty much need to rebuild everything.

Do you do out of core builds and installs? That's where you give cmake the
CMAKE_INSTALL_PREFIX option to tell it where to install stuff, and you give
cmake a final option about where to find the source.

For example, say you keep your source, build and install directories all
under a directory called $DIVERSE. It has a single directory, source, that
you downloaded DIVERSE into.

cd $DIVERSE
mkdir build
cd build
cmake -D CMAKE_INSTALL_PREFIX=$DIVERSE

/installed ../source

This will tell cmake to read files from the source directory and install in
the install directory.

If you change DGLWindow.cpp, you edit it in the source directory,
$DIVERSE/source/dgl/lib/dgl and run the "make install" command in the build
directory, $DIVERSE/build/dgl/lib/dgl

If you need to chanhe the include file, DGLWindow.h, you edit the source in
$DIVERSE/source/dgl/include/dgl. Build in $DIVERSE/build/dgl

Use the "j" option to make to do parallel makes. If you have two CPUs,
type: "make -j2 install" and things will go up to twice as fast.

DSO Example

In the exampleDSO.tar.gz you'll get the files:
exampleDSO/
exampleDSO/GNUmakefile
exampleDSO/exampleDSO.cpp

untar it, cd to exampleDSO, type
make and run the DSO. (Don't forget to have dgl-config and dtk-config in
your $PATH.)

You can then run it using the command:
> export DGL_DSO_FILES=desktopGroup

:exampleDSO
> dosg-fly --examine cow.osg

The DSO doesn't do much except print out the size of the first graphics
window, but does show you how to get the the Producer::RenderSurface
corresponding to the window, which might be handy. Eventually you'll want
to get all render surfaces for all windows, but we can deal with that later.

Here's an example of using a different DSO to get different behavior, and
might be handy for testing with multiple windows:
> export DGL_DSO_FILES=desktopGroup:hyperDisplay:exampleDSO
> dosg-fly --examine cow.osg

This DSO doesn't have every single callback used- it's not clear what
callbacks you need, and what you want the DSO to do. Let's get this one
working first, then later when the DSO's functionality is defined, I can
help you add more callbacks if they're needed.

If you need to add a DSO to the DIVERSE package itself, send it to me and
I'll test it and install it in DIVERSE for you. I think this would be saner
than you trying to mess with the DIVERSE package itself.

CCallBackHelix DTK Issue

We would like to have some information on how keyboard and mouse are controlled in the "CCallbackHelix" example.

When a mouse button is pressed, information on this button is displayed in the terminal
This is achieved by the pointer "button" from the line:

dtkInButton* button = (dtkInButton*) DGL::getApp()->get("buttons", DTKINBUTTON_TYPE);

We would like that mouse control is no more done this way but rather through Qt. We are currently writing a small application in Qt and when a mouse button is pressed on the Qt Window, mouse information is displayed on the terminal. We'll then try to implement this on the "CCallbackHelix" example.

We expect to have the following if we succeed:
- A window created with Qt in which we will display the Helix
- Mouse and keyboard events will be controlled in Qt

Questions
- Is the Producer API used to control the mouse in the "CCallbackHelix" example or is it through DTK?

------------------------------------------------------------------------------------------------------------------------------------
John replied:

When DIVERSE was first written, it ran only on X11 based systems such as
Linux and IRIX. DTK created some classes which use X11 to read the
keyboard, mouse and mouse buttons. When DGL was written by Andrew, he
decided to use Producer to handle the keyboard, mouse and buttons (and also
windows). He felt this would be the easiest way to support non-X11
platforms.

Except for bug fixes, DTK is basically a "frozen" project. The original DTK
developer is no longer around, so we pretty much use DTK as is. New
functionality is written in DGL.

Andrew came up with a way in DGL to feed data to DTK using Producer, so the
old X11 DTK code would still work. For example, the DTK trackballNav DSO
works with DGL's Producer code stuffing the mouse and buttons, but is
unchanged since it was originally written to use DTK's X11 code.

This is done in the DMKCallback class in the files
diverse/dgl/libs/dgl/DProducer

InputCallback.cpp and
diverse/dgl/include/dgl/DProducerInputCallback.h.

Other little DGL-only utility classes exist too: DGLKeyboard, DGLMouse,
DGLMouseButton. DTK doesn't use them, but they do use Producer.

Take a look in the DGLWindow class, and look for "DMKCallback". You'll see
it get set up in the postRealize() callback, and called every frame in the
updateKM() callback.

Testing installed software

John said:
-------------
The project as envisioned does not need DIVERSE's dpf or dads. It also
does not need CoVE.

As dpf isn't needed, neither is OpenGL Performer. OpenSceneGraph is only
needed if you choose to use dgl's dosg component. Inventor is also
optional.

The dgl example program "CCallbackHelix" should be sufficient to test your
software using different DSOs to describe various window configurations.
DSOs are also used to read the keyboard and mouse. You may choose to write
some of your own DSOs to print more verbose information about the state of
the system's windows and keyboard and mouse events.

The project in a nutshell is to replace the Producer component of dgl with
Qt, which is used to create and manage windows, and read from the keyboard
and mouse.