http://ftp.x.org/contrib/applications/xscreensaver-3.06.tar.gz

[xscreensaver] / driver / xscreensaver.man

diff --git a/driver/xscreensaver.man b/driver/xscreensaver.man
index 94754b17f2fca70865ad0facb7fa392764c7c791..ff978401ea6999d355bc3044fde4c7a6ecee74c0 100644 (file)
--- a/driver/xscreensaver.man
+++ b/driver/xscreensaver.man
@@ -11,7 +11,7 @@
 .if n .sp 1
 .if t .sp .5
 ..
-.TH XScreenSaver 1 "16-Nov-98 (3.04)" "X Version 11"
+.TH XScreenSaver 1 "22-Nov-98 (3.06)" "X Version 11"
 .SH NAME
 xscreensaver - graphics hack and screen locker, launched when the user is idle
 .SH SYNOPSIS
@@ -967,16 +967,30 @@ The
 .BR mwm (1)
 and
 .BR olwm (1)
-window managers don't seem to have this problem.  The race condition exists
-because X does not provide a way for an OverrideRedirect window to have its
-own colormap, short of grabbing the server (which is neither a good idea, nor
-really possible with the current design.)  What happens is that, as soon as
-the screensaver installs its colormap, \fBtwm\fP responds to 
-the \fBColormapNotify\fP event that is generated by re-instaling the default
-colormap.  Apparently, \fBtwm\fP doesn't \fIalways\fP do this; it seems to do
-it regularly if the screensaver is activated from a menu item, but seems to
-not do it if the screensaver comes on of its own volition, or is activated
-from another console.  Any thoughts on this problem are welcome...
+window managers don't have this problem.  The race condition exists
+because X (really, ICCCM) does not provide a way for an OverrideRedirect 
+window to have its own colormap, short of grabbing the server (which is 
+neither a good idea, nor really possible with the current design.)  What 
+happens is that, as soon as xscreensaver installs its colormap, \fBtwm\fP 
+responds to the resultant \fBColormapNotify\fP event by re-instaling the 
+default colormap.  Apparently, \fBtwm\fP doesn't \fIalways\fP do this; it 
+seems to do it regularly if the screensaver is activated from a menu item, 
+but seems to not do it if the screensaver comes on of its own volition, or 
+is activated from another console.  
+.RS 8
+.TP 4
+.B Attention, window manager authors!
+You should only call
+.BR XInstallColormap (3)
+in response to user events.  That is, it is appropriate to install a colormap
+in response to \fBFocusIn\fP, \fBFocusOut\fP, \fBEnterNotify\fP, 
+and \fBLeaveNotify\fP events; but it is not appropriate to call it in
+response to \fBColormapNotify\fP events.  If you install colormaps in
+response to \fIapplication\fP actions as well as in response to \fIuser\fP
+actions, then you create the situation where it is impossible for 
+override-redirect applications (such as xscreensaver) to display their
+windows in the proper colors.
+.RE
 .TP 8
 .B Colormap lossage: XV, XAnim, XEarth
 Some programs don't operate properly on visuals other than the default one,
@@ -985,8 +999,8 @@ magic "default-n" visual name in the description of the \fBprograms\fP
 resource in the \fIConfiguration\fP section.  When programs only work with
 the default colormap, you need to use a syntax like this:
 .EX
-    default-n: xv -root image-1.gif -quit  \\n\\
-    default-n: xearth -nostars -wait 0     \\n\\
+   default-n: xv -root image-1.gif -quit  \\n\\
+   default-n: xearth -nostars -wait 0     \\n\\
 .EE
 It would also work to turn off the \fBinstallColormap\fP option altogether,
 but that would deny extra colors to those programs that \fIcan\fP take