Geoff Levner (geoff++at++mclink.it)
Wed, 18 Nov 1998 09:09:24 +0100
I can think of three possible reasons why the GL drawing area should be
a child of a composite widget such as XmFrame, although whoever wrote
the sample code at SGI would know better than me:
1. Input events are handled by the parent widget, not by the drawing
area widget. This may be necessary if your application forks a process
to handle X events while your DRAW process is drawing to the drawing
area window, and probably speeds up your DRAW process (someone out there
correct me if I am wrong).
2. Theoretically you can close your drawing area widget, and then open
it again if you want to configure your frame buffer differently (to
toggle stereo or double buffering, for example). I say theoretically
because I have never gotten that to work. But if it did work, it is
probably simpler to change the child of an XmFrame than it is to change
your TopLevelShell or XmMainWindow.
3. When you resize your main window, an XmFrame automatically takes on
the new window size. I am not sure this is the case for a drawing area
widget.
In any case, when it comes to mixing Performer with Motif, my experience
has been that you are better off doing as the Performer doc says, even
when it doesn't explain why (as is generally the case). If the two are
not integrated just right, your application won't work, you won't get
any useful error messages, and you probably won't get any help from SGI.
If the XmFrame border bothers you, you can always set the border width
to zero, making it invisible.
-- Geoff Levner -- geoff++at++mclink.it OR glevner++at++hotmail.com ACS Studio, Via Aurelia 58, 00165 Rome, Italy tel. +39-063936331, fax +39-0639363317
This archive was generated by hypermail 2.0b2 on Wed Nov 18 1998 - 00:06:04 PST