staatsvr@asdcds.cds.wpafb.af.mil (Vern Staats; ASD/SCED;) (07/21/89)
I just translated the coloredit example in Doug Young's book from HP to Athena
widgets. My goals were to learn about using scroll bars and the wonderful new
virtual colormap capabilities of X11r3. Unfortunately, it appears that
virtual colormaps are uh, virtually useless (sorry, couldn't resist :-) under
the DECwindows window manager. Whenever I use XInstallColormap(...,my_map)
somebody (and I think its dxwm) goes and reinstalls the default colormap.
Is there some way to tell dxwm to leave my map installed, or at least
reinstall it when my application has focus?
------------------------------------------------------------------------------
Boolean orthogonal(char *my_opinions, char *employer_opinions) {return(TRUE);}
INET: staatsvr@asd.wpafb.af.mil /// Honey, I
UUCP: nap1!asd!staatsvr \\\/// dereferenced
Vern Staats, ASD/SCED, WPAFB OH 45433, 513-255-2714 \XX/ the kidsmsm@SRC.DEC.COM (Mark S. Manasse) (07/24/89)
Vern Staats writes: > I just translated the coloredit example in Doug Young's book from > HP to Athena widgets. My goals were to learn about using scroll > bars and the wonderful new virtual colormap capabilities of X11r3. > Unfortunately, it appears that virtual colormaps are uh, virtually > useless (sorry, couldn't resist :-) under the DECwindows window > manager. Whenever I use XInstallColormap(...,my_map) somebody (and > I think its dxwm) goes and reinstalls the default colormap. > > Is there some way to tell dxwm to leave my map installed, or at least > reinstall it when my application has focus? As you can see from reading the Inter-Client Communications Conventions Manual, obedient applications are enjoined from ever calling InstallColormap. Instead, applications that wish to install a single colormap are encouraged to use ChangeWindowAttributes to set that colomap as the colormap of their top-level window. It would have been nicer to allow applications to install colormaps freely, but the protocol does not provide the necessary support to avoid race conditions to allow it. 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
guido@cwi.nl (Guido van Rossum) (07/25/89)
Vern Staats writes: >> Is there some way to tell dxwm to leave my map installed, or at least >> reinstall it when my application has focus? Mark Manasse replies: >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). -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net "Repo man has all night, every night."
dshr@SUN.COM (David Rosenthal) (07/25/89)
> >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.
klee@gilroy.pa.dec.com (Ken Lee) (07/25/89)
In article <8286@boring.cwi.nl>, guido@cwi.nl (Guido van Rossum) writes: > Mark Manasse replies: > > >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'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. Actually, there are 2 different ICCCM proposals for colormaps. The X11R2 colormap proposal uses the RGB_COLOR_MAP property. This is used by the UWS2.1 version of dxwm and by the X11R3 XSetWindowColormap. The X11R4 colormap proposal (proposed in January and I think recently accepted as the standard) uses the COLORMAP_WINDOWS property. X11R4 clients using the COLORMAP_WINDOWS property will not work with properly the UWS2.1 dxwm. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee