Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!converse
From: converse@EXPO.LCS.MIT.EDU (Donna Converse)
Newsgroups: comp.windows.x
Subject: Re: Shared Colormaps
Message-ID: <9004111926.AA00967@expo.lcs.mit.edu>
Date: 11 Apr 90 19:26:03 GMT
References: <19365@boulder.Colorado.EDU>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 31


In article <9004051833.AA12124@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU
(Bob Scheifler) writes:
|>
|>    What I didn't expect was that part of the
|>    application created colormap was over-written with colors from the
|>    default colormap (only part of the read / write portion!!!)
|>
|>Sorry, I don't understand what you're saying.  What does "over-written"
|>mean?  If you mean RGB entries in your private colormap object are
|>permanently modified, then something is seriously wrong.


I took at look at this code and found that the programmer had misunderstood
XGetVisualInfo; specifically: the mistake was to think that VisualNoMask 
indicates that a visual structure is to be matched.  


One the same issue, another user writes:

> 	I had this happen to my private colormap object (unshared) 
> whenever my window lost keyboard focus.  I was running dxwm under
> DECwindows.  I fixed it by going to motif.

Colormap focus and keyboard focus are independent policies; they could both
depend upon the position of the mouse pointer for indicating focus.  The
rest of your statement is incomprehensible, sorry.


Donna Converse
converse@expo.lcs.mit.edu