jimf@saber.COM (04/25/91)
Assume that we have an application with a subwindow using a different visual
than its parent (so that the parent cannot have the subwindow's colormap), but
that we want the subwindow's colormap to be installed whenever the parent has
the colormap focus (even if the subwindow does not have focus at the time).
For the confused, this would be useful in some kinds of imaging applications.
Questions:
1. Is there some way under the current ICCCM to accomplish this? If so, how?
2. If there is no way to accomplish this, what kind of effort would it take
to get this capability added?
WM_COLORMAP_WINDOWS is almost there but it appears that the colormap will only
be installed when the focus is directly on the subwindow.
Auxiliary question: Which window managers, if any, currently support
WM_COLORMAP_WINDOWS?
Please answer via email.
jim frost
jimf@saber.comcflatter@zia.aoc.nrao.EDU (Chris Flatters) (04/26/91)
Jim Frost writes: > Assume that we have an application with a subwindow using a different visual > than its parent (so that the parent cannot have the subwindow's colormap), > but that we want the subwindow's colormap to be installed whenever the > parent has the colormap focus (even if the subwindow does not have focus > at the time). > > For the confused, this would be useful in some kinds of imaging applications. > > Questions: > > 1. Is there some way under the current ICCCM to accomplish this? If so, > how? > 2. If there is no way to accomplish this, what kind of effort would it > take to get this capability added? > > WM_COLORMAP_WINDOWS is almost there but it appears that the colormap > will only be installed when the focus is directly on the subwindow. I think that you are rather confused about this (it took me a long time to figure out section 4.1.18 of the ICCCM too). The relevant paragraph states: "Top-level windows that have subwindows, or override-redirect pop-up windows, whose colormap requirements differ from the top-level window should have a WM_COLORMAP_WINDOWS property. This property contains a list of window IDs of windows whose colormaps the window manager should attempt to have installed when, in the cause of its individual colormap focus policy, it assigns the colormap focus to the top-level window (see Section 4.1.10). The list is ordered by the importance to the client of having the colormaps installed. If this order changes, the property should be updated. The window manager will track changes to this property and will track changes to the colormap attribute of the windows in the property." Note that WM_COLORMAP_WINDOWS should be acted on when the top-level window get the focus not when the subwindow gets it. Basically, WM_COLORMAP_WINDOWS is an ordered list of window IDs. When the colormap focus passes to a window with this property set the window manager will look to see what colormap it requires and install it; it then looks at the second and installs its colormap (if different from the first window) and so on down the list until the maximum number of installed colormaps is reached or it hits the end of the list. The one wrinkle is that the top-level window is assumed to have a higher priority than any window in the list unless it actually appears in the list (if it does appear the window manager gives it the priority appropriate to its place in the list). So -- to go back to the original problem. The correct way of dealing with the problem is to set the WM_COLORMAP_WINDOWS list to <subwindow, parent> Assuming that your server only supports one installed colormap, the subwindow colormap should be installed when the colormap focus is in the parent. If you want the subwindow colormap to be installed only when the focus is in the subwindow you should set the list to <parent, subwindow> and change the order in the list when your client detects that the subwindow has the focus; the window manager should watch for WM_COLORMAP_WINDOWS being changed and act on it. > Auxiliary question: Which window managers, if any, currently support > WM_COLORMAP_WINDOWS? Any ICCCM compliant window-manager should support WM_COLORMAP_WINDOWS (or, to put it another way, writers of window managers should not claim that they are ICCCM compliant unless they do). Unfortunately there appear to be several window managers that are ICCCM compliant apart from support for WM_COLORMAP_WINDOWS. I am fairly certain that twm supports WM_COLORMAP_WINDOWS correctly. I have not had an opportunity to test this aspect of mwm, which is claimed to comply with the ICCCM (I don't have access to an X11R4 setup with OSF/Motif). Sun's olwm does act on WM_COLORMAP_WINDOWS but does so incorrectly and the current version of XView expects the window manager to behave in the same (incorrect) fashion. The Sun window manager installs the colormap of any window that appears in the list when that window receives the colormap focus. I was told that this will be fixed in the next release of XView. Chris Flatters
nazgul@alphalpha.com (Kee Hinckley) (04/27/91)
In article <9104260321.AA20403@zia.aoc.nrao.edu> cflatter@zia.aoc.nrao.EDU (Chris Flatters) writes: >parent. If you want the subwindow colormap to be installed only when >the focus is in the subwindow you should set the list to > > <parent, subwindow> > >and change the order in the list when your client detects that the subwindow >has the focus; the window manager should watch for WM_COLORMAP_WINDOWS being >changed and act on it. This is probably what you usually want. >I am fairly certain that twm supports WM_COLORMAP_WINDOWS correctly. When I make the call XtSetWMColormapWindows(shell, &widget, 1); tvtwm crashes. I've looked at its code for handling that stuff and it may not be broke, but it's definite baroque. Line 2564 in events.c, where it says if (cmap->state & CM_INSTALL) { cmap is an invalid pointer. Am I doing something wrong, or is it? -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Dave.Rosenthal@eng.sun.COM (David Rosenthal) (04/30/91)
> Assume that we have an application with a subwindow using a different visual > than its parent (so that the parent cannot have the subwindow's colormap), but > that we want the subwindow's colormap to be installed whenever the parent has > the colormap focus (even if the subwindow does not have focus at the time). > > For the confused, this would be useful in some kinds of imaging applications. > > Questions: > > 1. Is there some way under the current ICCCM to accomplish this? If so, how? Sections 4.1.2.8 (page 518 of the Digital Press 2nd Edition) and 4.1.8 (page 527) describe the WM_COLORMAP_WINDOWS property. Nowhere do they say anything about Visuals - the mechanism they describe works irrespective of whether the subwindows have the same Visual as the top-level window. How did you get the idea that there was a difference? > 2. If there is no way to accomplish this, what kind of effort would it take > to get this capability added? > The capability you want is already in the ICCCM. > WM_COLORMAP_WINDOWS is almost there but it appears that the colormap will only > be installed when the focus is directly on the subwindow. > Section 4.1.8 says: The window manager will define some colormap focus policy and, whenever the top-level window has the colormap focus, will attempt to maximize the number of colormaps from the head of the WM_COLORMAP_WINDOWS list that is installed. Again, the ICCCM specifically says that the effect you want is to occur. How did you get the idea that it would not? (note that the colormap focus need not be tied to the input focus - that is a WM policy decision). > Auxiliary question: Which window managers, if any, currently support > WM_COLORMAP_WINDOWS? > Any ICCCM-compliant window manager must implement WM_COLORMAP_WINDOWS. It is not an optional part of the ICCCM. David.