Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!wind!naughton
From: naughton@wind.Eng.Sun.COM (Patrick Naughton)
Newsgroups: comp.windows.x
Subject: Re: Colormaps and override-redirect windows
Message-ID: <4190@exodus.Eng.Sun.COM>
Date: 8 Dec 90 01:43:41 GMT
References: <1990Dec7.113139.10325@tcom.stc.co.uk>
Sender: news@exodus.Eng.Sun.COM
Reply-To: naughton@wind.Eng.Sun.COM (Patrick Naughton)
Organization: Sun Microsystems, Inc. - Mountain View, CA
Lines: 25

In article <1990Dec7.113139.10325@tcom.stc.co.uk>, graham@tcom.stc.co.uk (Graham Bardsley) writes:
|> 
|>   I guess this subject has been covered before but how do I create an application
|> whose only window is an override-redirect window which covers the whole screen
|> and has a different colormap to the one which the window manager uses? Does this
|> sound familiar, I suppose xlock is an example of such an application. When I run
|> xlock under tvtwm, when the window is mapped, tvtwm re-installs its own
|> colormap. If I tweek xlock to reset the colormap whenever it gets a
|> ColormapNotify event, you get the application fighting the window manager to
|> maintain its own colormap. Unless I've missed something, the ICCCM says 
|> nothing about this class of applications, so is this a matter that needs 
|> clearing up?

XLock no longer fights with window managers... it simply allocates a
small number of shareable colors out of the default colormap.  As it
turns out, there was no real solution offered by the ICCCM since xlock
does not have a top-level non-override-redirect window on which to set
the WM_COLORMAP_WINDOWS property.

-Patrick

-- 
    ______________________________________________________________________
    Patrick J. Naughton				    ARPA: naughton@sun.com
    Sun Microsystems, Inc.			    AT&T: (415) 336 - 1080