madd@bu-cs.BU.EDU (Jim Frost) (10/12/89)
I need to know what the "proper" way to set the root window's colormap and/or pixmap is. I am currently just setting the window attributes, which works under some window managers but appears to confuse others terribly. What is the "right" way? jim frost software tool & die madd@std.com
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/12/89)
I need to know what the "proper" way to set the root window's colormap
and/or pixmap is.
The ICCCM has this to say:
Window managers will ensure that the root window's colormap field
contains a colormap that is suitable for clients to inherit;
in particular the colormap will provide distinguishable colors
for BlackPixel and WhitePixel.
From this I think one should infer that the window manager owns the colormap;
any mechanism for allowing clients to change it would at present be nonstandard.
Changing the root window background is less problematic, but you may be
fighting against a window/desktop manager's style guide in doing so.madd@bu-cs.BU.EDU (Jim Frost) (10/13/89)
In article <8910121410.AA19693@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: In a previous artile, I write: | I need to know what the "proper" way to set the root window's colormap | and/or pixmap is. |From this I think one should infer that the window manager owns the colormap; |any mechanism for allowing clients to change it would at present be nonstandard. Perhaps we should make a standard? It's certainly pleasant to put a picture on the background, particularly a color picture. I've noticed from playing with different window managers that setting the root window colormap sometimes works, but it always works if you only allocate colors in the default colormap. Unfortunately there usually aren't very many free colors on 8-bit displays (and none on 16). While my particular application is pretty good at squashing colormaps to fit, it often doesn't look nearly as nice as otherwise. Intuitively I would guess that setting the default colormap would be the "right" thing to do, but I'd be willing to bet that most window managers wouldn't deal with that correctly. |Changing the root window background is less problematic, but you may be |fighting against a window/desktop manager's style guide in doing so. Oh well :-). Seriously, given how user-configurable X is, this kind of thing ought to be taken as a given. jim frost software tool & die madd@std.com
toml@Solbourne.COM (Tom LaStrange) (10/13/89)
> I need to know what the "proper" way to set the root window's colormap > and/or pixmap is. I am currently just setting the window attributes, > which works under some window managers but appears to confuse others > terribly. What is the "right" way? Very good question. From some of the work we have done here, we too have found that setting the colormap of the root window to be a desirable thing to do. If you have a bunch of clients that wish to use a standard colormap such as RGB_BEST_MAP, it is useful to set that colormap on the root window so that applications can use it rather than creating there own. Since most applications create their windows while simply inheriting the colormap of their parent this should not present too many problems. There is a problem however in current window managers. Here is the problem, at least with twm: When the window manager starts up, it uses DefaultColormap(dpy, screen) as the colormap to install when the pointer is on the root window. It also uses this colormap when allocating colors for title bars, menus, etc. Basically the colormap currently in the root window's attributes is ignored. What should probably be done is for the window manager to find out what colormap is currently in the root window's attributes and install it and use it for its default colormap. This also requires that the window manager watch for colormap changes on the root window. What this buys the user is the ability to set a standard colormap (such as RGB_BEST_MAP) on the root window and have all clients, including the window manager, use it instead of the default colormap. This eliminates the "technicolor" flashing as the user moves between applications that are using this standard common colormap. This is not a difficult change, we have already changed the yet to be unveiled swm (Solbourne Window Manager) to do just what I have described and have noticed no problems whatsoever. I would also be more than happy to provide a patch for twm to allow this functionality. One other interesting problem arises. Since most Xt clients inherit the colormap of the root window, setting that colormap to a standard colormap may cause problems. A standard colormap may not have any cells that can be changed. This causes Xt clients to fail when trying to allocate a named color. Solbourne's Xt clients have been fixed so that they use the closest color available when no color cells can be allocated. We expect MIT to provide a similar fix in the future. -- Tom LaStrange Solbourne Computer Inc. ARPA: toml@Solbourne.COM 1900 Pike Rd. UUCP: ...!{boulder,nbires,sun}!stan!toml Longmont, CO 80501
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/13/89)
If you have a bunch of clients that wish to use a standard colormap
such as RGB_BEST_MAP, it is useful to set that colormap on the root
window so that applications can use it rather than creating there own.
You must mean something different here, Xlib provides a mechanism for
clients to get at an RGB_BEST_MAP without having to create their own.
Clients wishing to use a standard colormap need more info that just
the colormap id, so making it to root window's colormap is not sufficient.
I assume you really just mean that it would work better if that particular
colormap was the same one used by applications that don't use standard
colormaps. If so, have your session or window manager create the RGB_BEST_MAP
"in place" in the default colormap, before the "real" clients start up. It
isn't that difficult to do. I don't see that any additional mechanism is
necessarily required.
We expect MIT to provide a similar fix in the future.
Putting words in MIT's mouth can be a dangerous thing. We have started
thinking about the interaction between Xt and standard colormaps, but
the nature of the best solution is far from clear right now.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/14/89)
For example, they might check if the colormap they inherited is one
of the defined standard colormaps. If it is, they then know how
to map named colors to indicies.
This doesn't sound like the best idea to me.
Or, they might inspect a special
resource which would indicate whether to try and use a standard
colormap. For example, xterm*standardColormap: rgb_best_map.
Good, but then inheriting from the root is not interesting.
Is is really possible to allocate *all* colors out of the default map?
It isn't a good idea, no. Sorry, I was forgetting RGB_BEST_MAP vs
RGB_DEFAULT_MAP.
How is the client to know that the default map has a standard colormap
allocation?
A normal client shouldn't really need to know. It may have to worry about
allocation failures, but it has to worry about that anyway.
Wouldn't this break Xt clients, since they currently have
to allocate color cells?
RGB_BEST_MAP was a bad example; you can still create an RGB_DEFAULT_MAP out
of the default map, and leave room for a reasonable number of clients to
allocate. If your goal is really to create an RGB_BEST_MAP and have everybody
use it, make your server define a StaticColor visual and make it the default.
(Half :-).