Path: utzoo!attcan!uunet!lll-winken!brutus.cs.uiuc.edu!apple!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: Virtual colormaps & DECwindows
Message-ID: <8907242205.AA00499@devnull.sun.com>
Date: 24 Jul 89 21:30:37 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 79

> >The currently-shipped version of dxwm keeps 
> >track of what it believes to be the focus window for colormap, and 
> >keeps that window's colormap installed.  Since the current release 
> >of dxwm predates the ICCCM's adoption of COLORMAP_WINDOWS, it does 
> >not implement that feature of the ICCCM.
> >
> >Mark
> 
> Mark's explanation seems to imply that you can't get a colormap
> installed at all by dxwm, but life isn't that bad.  Some playing with
> Doug Young's coloredit example (which needs some lay-out changes for 256
> colors, BTW!) reveals that calling XSetWindowColormap(display, window,
> colormap) works, both for twm and for dxwm.  Young claims this is
> the ICCCM-conformant way.  The colormap is uninstalled when the
> application loses the color focus and reinstalled when it regains it.
> (dxwm seems to maintain separate color and keyboard focuses; with twm,
> the color map seems to simply follow the keyboard focus).
> 
There is some confusion in these messages.  To summarize the
information in sections 4.1.2.8 and 4.1.8 of the ICCCM:

One colormap at a time may be associated with a window with:

	XCreateWindow()
	XSetWindowColormap()
	XChangeWindowAttributes()

In other words,  a colormap is one of a window's attributes.

If a client creates sub-windows of one of its top-level windows
that have colormap attributes DIFFERENT from their top-level
window,  then the ICCCM specifies that the names of these
sub-windows should appear in a WM_COLORMAP_WINDOWS property on
the top-level window.  The name of the top-level window may
or may not appear in this list;  the effect will always be as if
it appeared in the list.

A non-existent WM_COLORMAP_WINDOWS property behaves the same as
a property containing the name of the top-level window.  Thus,
Young is correct in claiming that the ICCCM-conformant way to
tell the window manager about your colormap is to set your
top-level window's colormap attribute ONLY if none of its
sub-windows have other colormaps.

ICCCM-compliant window managers will watch the windows in the list
(including the top-level window) for changes in their colormap
attributes.

Setting the colormap attribute of a window has no visible effect.
A colormap has to be installed before it has a visible effect.
Clients should NOT install or uninstall colormaps.  Even before
the final ICCCM,  installing was not neccessary for clients whose
top-level windows and their sub-windows all used the same colormap
(the one which was an attribute of the top-level window).

Because of race conditions in the protocol,  clients that attempt
to install their own colormaps cannot be guaranteed to work.  The
ICCCM makes the window manager responsible for installing and
uninstalling colormaps,  in order to avoid these races.  The policy
by which it decides which maps to install when is up to the WM.
The order of the entries in the WM_COLORMAP_WINDOWS property
will control the relative importance the window manager will attach
to having those maps installed whenever it decides that the top-level
window has the "colormap focus".

I understand that people may find it awkward that the mechanism
for dealing with colormaps has changed,  and that it does not work
if no window manager is running.  But it is important to realize
that:

a)	The previous techniques did not work reliably.
b)	The change only affects clients which have sub-windows
	whose colormap attributes differ from those of their
	top-level windows.  These clients face problems anyway,
	in that most hardware can only install a single map at
	a time and on this hardware these clients will NEVER
	appear entirely in their correct colors.

	David.