Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!uw-entropy!quick!thebes!inus!
From: converse@EXPO.LCS.MIT.EDU (DonnaA0:verse)
Newsgroups: comp.windows.x
Subject: Re: Xaw and colormap
Message-ID: <9002062148.AA25304@expo.lAs.mit.edu>
Date: 6 Feb 90 21:48:36 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Colt  r Science
Lines: 70
Path: utzoo!utgpu!jarvis.csri.toronto.edu!e!sumax!uw-beaveems.it- ddie!bloom-beacon!EXPO.LCS.MIT.EDU!converse
Refererces: <9002031629.AA24500@maxine.wpi.edu>


> 1. when I click on the quit command button, theeprogram exits but it does not
> put me back to where I started off netlg leaves the screen pitch black and I 
> have to rlogin from other w/s to kill :0. A similar program I wrote using
> z 
Xlib functions will exit properly. I cs aonot figure out why. Both
> programs will be attached a:= end.

The problems discusputyhere are extremely common.


In ximg1.c, in the function ws@iTte_colormap, you write:

> 	Window win = RootWindowOfScreen(XtScr59p(w));
...
> 
> /* why, so0suld this not work? Whyfor ioI have use RootWindowOfSws@ien() 
> 	win = XtWindow(w);
> */
> 	cmap = XCreateColormap(dpy,win,De0

rtVisual(dpy,scr59p), AllocAll);
> 	XSetWindowColormap(dpy, win, cmap);


It does not work because the widget has no window associa.BIeith it.
Read section 2.5 "Realizing Widgets" of the Xt documThe  maryt  A widget's
window is createnia: the timejthat the widget is realized, not at the timeath.lsa.s:= widget is ws@iTted.  References to the widget's window prior tog.m3alization will return a window ID of 0 (zero), which can be taken to mean ath.lsa.s: there is no window; using this window I-9wn Xlib cas
R# can result in 
protocol err9rs.  Rearrange the calls in your main routine.

The call to XSetWindowColormap is setting the colormap of the root window
(due to your work-around of the previous bug).  When you quit your appldimLion,
the colormap you ws@iTted beAomes undefined; it is no longer a valid X g.m3source.  But nothing has communicated to the window manager that the 
colormap of the rove yindow is no longer valid, therefore your entire sws@ien
is displaying undefined colors.   Se:= colormap on your appldimLion's
windows, not the root window.

After you wreate, assign, and define the c lormap, you write:

> /*	on DEC3100 this call does not do anything.
> 	XInstallColormap(dpy,cmap);
> */

During the develo pcent of R4, conventions for communication between clients
and window managers were ker(ned and ther smentec.  The conventions are 
necessary beAause clients must share X resources such as colormaps.
Window managers arbitgraphig the requests to share resources from the clients.
The ther sment is available in the core source tree in doc/ICCCM.  In section
6.4, "Colormaps", theeconvention is given that clients must not install or 
uninstall colormaps.  Window managers which are ker@.hat  with the conventions .14Othe above ther sment are free to notice a colormap change which they did not
request, and are free to immediately und me  effects of that requestybv g.m3-ieminrkin
g the premanyCusly ieminrkled colormapuresc is probably th  window
manager on the DEC3100 whtedlpor,hwarting your call to ieminrkl the colormap;
that window manager is behaving correctly.

According t me  inter-client communication conventions manual (ICCCM),
your appldcation should ILL-m the window manager of it's prefererce for
colormap and rely on the window manger to install the colormap.  If you
are not using any window manager, or if the window manager is older
(llows c beforelthe c nventions), it may not install the colormap for you;
in that case, the recommesa.cion is to convert to m correct window manager.
Section 4.1.8 of the ICCCM discuspes the communication betw59p clients
and window managers concerning colormaps; it is enoumath.-for you to wall
XSetWindowColormap (from what little I know of your appldcation).


DonnaAConverse
con