GLXwin must make sure that its colormaps are installed in order for
images to appear correct.  X clients notify the window manager about
colormaps by setting the WM_COLORMAP_WINDOWS property on the
appropriate toplevel window.  GLXwin contains code to automatically
perform this property initialization.  

GLXwin's task is slightly more complicated than normal because it
creates subwindows of the main window to support overlays, underlays,
and popups, but these windows are not Tk windows.  In other words,
Tk does not know about them at all.

Other packages, such as the publically available Photo widget, also
contain code to install colormap information.  In fact, the colorfocus
patch to the Tk library  that is distributed with the Photo widget
provides a general and automatic way in handle colormap installation.

Well, almost.  colorfocus only knows about Tk windows, and it also
assumes that it is in complete charge of handling the
WM_COLORMAP_WINDOWS property.  It blows away the changes made by
GLXwin when it sets the property to what it thinks is correct.

So, life is not grand.  I've discussed the problem with the author
of the Photo widget/colorfocus, and hopefully we'll figure out the
best way to deal with the problem.  Until then,  for those of you
who have patched your Tk libraries with the colorfocus patch, you 
must tell colorfocus to forget about the GLXwin windows.  

The following proc does the right thing, and looks to see if the 
colorfocus command exists before attempting to explicitly install
the GL colormaps.  Call this command once (although calling it
several times won't hurt anything), perhaps in response to a <Map>
event:

proc glx_install_colormaps {w} {
    if {[info commands colorfocus] != ""} {
	colorfocus remove $w
	$w installcolormaps
    }
}
