mlandau@DIAMOND.BBN.COM (Matthew Landau) (08/09/90)
I have a bit of a problem getting custom colormaps installed on my
windows -- perhaps someone in X-land can provide some advice.
The situation is this: I'm using X11R4 with all the latest patches
from MIT. I have a program that creates a top level window and some
subwindows of that top-level window. All of the windows are created
in the DefaultVisual, which happens to be a PseudoColor Visual on
the machine in question, and all of them are initially created with
the DefaultColormap.
At some point during the execution of my program, I create a new
Colormap using the appropriate Visual, allocate all of the color cells
in the new map, use XStoreColors to set RGB values in the new map,
and then use XSetWindowColormap to install this colormap on ALL of
my windows (both top-level and subwindows).
Using XQueryColors reveals that the colors are correctly set in the
Colormap. Using xlswins to find the subwindow id's and xwininfo to
print their attributes reveals that both the top-level window and
all of the subwindows do, indeed, have the correct Colormap value set.
However, I'm having a devil of a time getting some window managers
to install this colormap when the pointer moves into the top-level
window.
The behavior I'm seeing depends on the window manager in use:
* twm (X11R4 version, with all patches) NEVER installs the
top-level window's colormap.
* olwm (both the version on expo and the binary shipped with
OpenWindows 2.0) installs the colormap for SOME invocations
of the program, but not others. In other words, you can
invoke the same program twice, with the windows sitting side
by side on the screen, and one of them will have its colormap
installed as the pointer enters it while the other will not.
There is NO discernable difference in the properties, hints,
or attributes of the two top-level windows or of their
corresponding subwindows.
* mwm on the IBM RS/6000 works correctly; i.e., colormaps are
installed and uninstalled as you would expect.
* dxwm in DECWindows 2.2 seems to work correctly, at least until
it dumps core. (But then again, we've found that dxwm dumps
core if you look at it wrong...)
Frankly, I'm baffled. The three possibilities that occur to me are:
1. There is some sort of race condition in installing a colormap,
2. I'm confused about whether or not I'm supposed to be using
WM_COLORMAP_WINDOWS, or
3. Olwm and twm are both just buggy, and don't cope well with
clients that change their Colormap after their windows are
created.
I'm disinclined to believe in race conditions, because xwininfo says
that the Colormap attributes ARE being set on these windows - the
window manager is just ignoring them.
I don't THINK I need to be setting WM_COLORMAP_WINDOWS on my top-level
window, based on a reading of Section 4.1.8 of the ICCCM, which says
"Top-level windows that have sub-windows, or override-redirect
popup windows, whose colormap requirements differ from the
top-level window should have a WM_COLORMAP_WINDOWS property."
In my case, the colormap requirements of the subwindows are IDENTICAL
to the requirements of the parent window. The only reason I'm using
XSetWindowColormap on the subwindows is because I'm changing the
Colormap of the top-level window, and want to change the Colormaps of
the subwindows to match. Is there some other way I should be doing
this? [Yes, I *know* I'm one of the people who worked on that part
of the ICCCM, but I honestly don't remember what we had in mind, or
if we ever discussed this particular situation.]
Finally, it's possible that twm and olwm are both just buggy, which
would be rather bad news for my commercial software products, since
they're two of the more widely used window managers. If buggy window
managers are to blame, perhaps someone has a suggestion for a
workaround?
--
Matt Landau Waiting for a flash of enlightenment
mlandau@bbn.com in all this blood and thunder