Dan.Nydick@FARADAY.ECE.CMU.EDU (03/28/89)
I've written a widget which maintains its own colormap. Things work OK
except for interactions with the various window managers (awm, uwm, twm).
First of all, none of the window managers will install my widget's colormap
automatically---I'm assuming this is because the widget's window is a
sub-window of a shell widget, and not directly controlled by the
windowmanager. My solution to this problem was to bind an action to the
<EnterWindow> and <LeaveWindow> actions, one which calls XInstallColormap
and the other which calls XUninstallColormap. This works fine running
awm or no wm at all, but twm or uwm see my widget fooling with the colormap
and promptly switch it back.
The questions:
1) Did I miss the "right" way of doing this? (ie: should
my widget really be calling XInstallColormap?)
2) If my widget is supposed to call XInstallColormap, how do I
tell the window managers not to instantly switch the
colormap back?rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/28/89)
1) Did I miss the "right" way of doing this? (ie: should my widget really be calling XInstallColormap?) You should not be installing your own colormap. The draft standard of the ICCCM tells you what to do. Unfortunately, the public window managers you are likely to get your hands on probably don't implement this aspect of the ICCCM (the R3 window managers certainly don't). Someone will have to do the work. (We expect to have at least one ICCCM compliant window manager in R4.)
tom@ICASE.EDU (Tom Crockett) (03/29/89)
> *Excerpts from xpert: 28-Mar-89 Re: widget with colormap Bob* > *Scheifler@expo.lcs.m (491)* > We expect to have at least one ICCCM compliant window manager in R4. Which one?
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (03/29/89)
> We expect to have at least one ICCCM compliant window manager in R4.
Which one?
Not uwm. (In fact, uwm is being orphaned...)stroyan@hpfcdc.HP.COM (Mike Stroyan) (03/29/89)
> 1) Did I miss the "right" way of doing this? (ie: should > my widget really be calling XInstallColormap?) Don't call XInstallColormap. It is antisocial. The current ICCCM draft discusses telling the window manager by setting the WM_COLORMAP_WINDOWS property of the top-level window. The property contains a list of window ids for which the window manager should install the colormaps for when the application has colormap focus. The list is ordered in descending priority. A subwindow's colormap can be made more important by listing the top-level window after the subwindow. Otherwise the top-level window will have highest priority. Unfortunately, most window managers don't yet observe the WM_COLORMAP_WINDOWS property. For now you probably can get the effect you want by changing the colormap attribute of the top-level window whenever the widget is entered or exited. You can either keep the window id in a global variable or follow the widget parent entries to the top widget. If the parent window and widget window have different visuals, then this method can't be used. Mike Stroyan, stroyan@hpfcla.hp.com
bobtl@tekecs.GWD.TEK.COM (Bob Toole) (03/30/89)
In article <8903281206.AA23640@faraday.ece.cmu.edu> Dan.Nydick@FARADAY.ECE.CMU.EDU writes: > 1) Did I miss the "right" way of doing this? (ie: should > my widget really be calling XInstallColormap?) I think this is a mistake. I've done a lot of work fiddling with colormaps. What I have to do is build my own colormap and set the shell widget to use my colormap. The sequence is important here. First the XtInitialize to open the display, then build my colormap(s). Set the colormap of the widget, now realize the widget. I use a variant of awm which installs the colormap nicely. I believe vanilla awm should do the same thing. Awm at least is intelligent enough to use the colormap of the window it is reparenting. I also put a switch in my programs so that they can install/deinstall colormaps, but only as a last resort. This is only for when there is no window manager or a non-compliant window manager. I leave it up to the user as to when to use the switch. It will be nice when that can go away completely. Bob Toole bobtl@tekecs.GWD.TEK.COM