RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (10/20/87)
Date: Fri, 16 Oct 87 15:54:15 PDT
From: Geoff Kuenning <bilbo.geoff@SEAS.UCLA.EDU>
I have been working on an application that wants a lot of colors, and
thus must often use its own color map. However, the window-manager experts
tell me I should never do my own XInstallColormap calls. This seems
reasonable enough, but what about when there is no window manager? Logic
dictates that I should simply make my window's color map be the private
one, and forget about it. If I have a window manager, it should catch
the ColormapNotify and do the "right" thing, whatever that is.
The truth is, there is precious little X experience with multiple
colormaps and how to handle them, and it isn't very clear yet when
window managers will start to deal with them, or what the application
strategy should be in coping with lack of such support (either no window
manager at all, or a window manager that doesn't do colormaps). Note
that (un)install operations are done on colormaps, not on windows, and
there is no mechanism to get such requests diverted to a window manager,
although a window manager can get notified after the fact. It is
possible that, with experience, additional protocol support will be
desired, but it seems to me that the first order of business has to be
to try and crystalize what the desired user interfaces are, and then
figure out if and how they can be mapped onto the protocol. Discussion,
perhaps on the xtensions list, would be welcome.
If I don't have a window manager, I would expect that, as the mouse enters
the window, the server would install the proper color map. However, in
looking at the code in "dix", I can't see anything that would do this.
That would be a particular policy, one that would work well sometimes,
and work poorly at other times. For example, if the keyboard focus is
set on a particular window, and you aren't using the pointer, you might
well just shove it off to a corner somewhere. It would be very
undesirable if the application you were typing at went technicolor as a
result. Similarly, consider pressing a button in a window, and then
moving around before releasing, perhaps even moving outside the window
boundaries (which is reasonable in various situations) or into subwindow
boundaries that aren't particularly relevant at the instant. Again, you
probably wouldn't want the window you are interacting with to go
technicolor.
In fact, as far as I can tell, a window's color map isn't really used;
it's just recorded and passed around. In that sense it's more like a
property than a window field.
The colormap attached to a window informs the server (and clients) as to
the desired way to transform pixel values into color. When there are
more logical (X resource) colormaps than physical (hardware) colormaps,
there has to be some way to establish which maps "win". InstallColormap
provides a way to guarantee that certain maps "win", and hence the
corresponding windows will display with true colors. If the desired
logical set is smaller than the available number of hardware maps, then
the server is free to choose additional maps, hopefully maps of visible
windows. You won't see a window's colormap being used by the sample
server, because the usage would be in the ddx layer, and we haven't
provided a sample for anything with multiple hardware maps, and the
implementation for a single hardware map doesn't try to be at all clever
about filling in unused hardware map entries with used entries from
other logical maps. Given hardware capable of having a separate
hardware map per window, for example, the information would certainly be
used.