young@BULLWINKLE.UNM.EDU (Mark Young) (08/15/90)
Hi,
We are trying to implement an application under X11R4 (patches 1 - 14)
on a DecStation 3100, while running the twm window manager. In this
application, we would like to have the toplevel widget with the default
colormap, while several children of this toplevel widget have a different
colormap. We are attempting to use the XSetWMColormapWindows() routine
without much success. The ICCCM guide says that XSetWMColormapWindows()
is the proper way to notify R4 window managers to install colormaps for
subwindows. We are using the following routine to change the colormap for
an existing widget:
set_colormap(toplevel, child, colormap)
Widget toplevel, child;
Colormap colormap;
{
int i, val;
Arg arg[1];
Window toplevel_window = XtWindow(toplevel),
child_window = XtWindow(child);
/*
* Set the widget's colormap
*/
i = 0;
XtSetArg(arg[i], XtNcolormap, colormap); i++;
XtSetValues(child, arg, i);
/*
* Set the window's colormap and let the window manager know that
* the following inferior window has a different colormap.
*/
XSetWindowColormap(display, child_window, colormap);
if (XSetWMColormapWindows(display, toplevel_window, &child_window, 1))
printf("Colormap set for widget %s\n", XtName(child));
else
printf("Failed to set colormap for widget %s\n", XtName(child));
}
We always get the print statement saying that the colormap has been set;
however the colormap is not being changed on the inferior window for
either twm, gwm, or mwm. The colormap is installed when we use olwm.
I think mwm and gwm maybe R3 based, but twm is R4 based, which the new
WM routines are supposed to work for. Can anyone help clarify what's
going on? Any help would be greatly appreciated.
thanks in advance,
Mark
ps. while in dbx we notice that twm recieves the colormap changes
for the inferior windows (in FetchWmColormapWindows), but doesn't
seem to use it for an EnterNotify event (in InstallWindowColormap).
------------------------------------------------------------------
Mark Young young@houdini.unm.edu
University of New Mexico (505) 277-5501 (work)
Albuquerque, NM 87131 (505) 242-2427 (home)
------------------------------------------------------------------asente@adobe.com (Paul Asente) (08/16/90)
The DS3100 you're using (and, indeed, most workstations out today) have only one colormap. If you have an application that uses three colormaps for three different windows, only one of them will ever be active. Window managers only install colormaps for top level windows, they are completely oblivious to inferior ones. As a consequence, only your top level window is ever getting its colormap installed. Setting the colormap windows *is*, however, the right thing for you to be doing, since it means that your application will display correctly if it ever happens to run on a workstation that can support three colormaps. With the ICCCM as it is, there's really no way for you to internally manage your colormaps (for example, by installing the colormap of a subwindow when the cursor enters it). The most portable thing for you to do is to have each widget tree (i.e. shell widget and all its non-popup children) use the same colormap. In other words, the children that have different colormaps should each be in a separate popup tree. If you absolutely need the behavior you specify, you'll probably have to implement your own, non-ICCCM window manager. -paul asente New address! asente@adobe.com ...decwrl!adobe!asente
bruce@servio.UUCP (Bruce Schuchardt) (08/17/90)
ICCCM specifies a COLORMAP_WINDOWS property that you can set with a list of the windows containing colormaps that you want the window manager to pay attention to. Window managers have to deal with this list somehow - mwm provides a colormap cycling function to allow the user to sequence through the colormaps in the list with the press of a button. Here's the ICCCM excerpt: WM_COLORMAP_WINDOWS The WM_COLORMAP_WINDOWS property, of type WINDOW, on a top-level window is a list of the the IDs of windows that may need colormaps installed that differ from the colormap of the top- level window. The window manager will watch this list of windows for changes in their colormap attributes. The top-level window is always (implicitly or explicitly) on the watch list. See Section 4.1.8 for the details of this mechanism. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Bruce Schuchardt Ph: (503) 629-8383 Servio Logic bruce@servio.SLC.COM Beaverton, OR uunet!servio!bruce
stroyan@hpfcso.HP.COM (Mike Stroyan) (08/21/90)
> With the ICCCM as it is, there's really no way for you to internally manage > your colormaps (for example, by installing the colormap of a subwindow when > the cursor enters it). The most portable thing for you to do is to have each > widget tree (i.e. shell widget and all its non-popup children) use the same > colormap. In other words, the children that have different colormaps should > each be in a separate popup tree. > -paul asente You _can_ manage the colormaps of subwindows with ICCCM rules. You can ask the window manager to favor particular subwindows by updating the order of windows in the WM_COLORMAP_WINDOWS property when the mouse enters and leaves subwindows. The problem with doing this is that very few window managers are correctly implementing the ICCCM behaviour. Mike Stroyan, stroyan@fc.hp.com