Path: utzoo!news-server.csri.toronto.edu!rutgers!bellcore!uunet!ora!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Colormap dilemma
Message-ID: <9103140616.AA06860@lightning.McRCIM.McGill.EDU>
Date: 14 Mar 91 06:16:53 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 49

> I am currently working on a product that contains two separate X
> client applications with 128 colors each (same 128 colors for both
> applications).  These 128 colors have to be settable (read/write) by
> the application.

Which one gets to set them?  How do the applications make sure that
they both want the same values in all 128 slots at the same times, if
they change?

> 3. Using XAllocColor() to try to get the exact colors we request in
>    each application from the default colormap.

I thought you said the colormap cells had to be read/write.
XAllocColor allocates read-only cells.

> Are there other alternatives for what I am trying to do, or do I need
> to choose between the lesser of two evils (2 and 3)?

One possibility comes to mind: have the first client to start up
allocate the cells in the default colormap (or, if that's not possible,
create a new colormap and allocate them there).  This allocation is
done on a separate connection created specifically for the purpose,
with a close-down mode of RetainPermanent.  Later clients find out
about this through window properties.

I don't think you can completely avoid possible problems in case some
client uses XKillClient to free up your allocation.  The first thing
that comes to mind is to stash the information in a property on the
root.  While this will work, it is fragile in the face of XKillClient
being used to destroy the allocations.  (It would be nice if there were
some way to specify that a property should not survive beyond some
client's "destruction of resources" point, meaning either connection
shutdown or XKillClient, as the case may be.)  A somewhat more robust
scheme would be to create a window somewhere, put the information on a
property on it, and then put its ID in a property on the root.  (The
window should be 1x1 - as small as possible - to conserve resources and
should probably never be mapped; it might even be completely
off-screen.)  This way, if the resources are destroyed either the
window ID will be invalid or, if it gets reused, it won't have the
magic property on it.

Of course, the testing and setting of these properties has to be done
with the server grabbed.  This is unfortunate, but I see no way of
getting around it.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu