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
 ..
 .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
 .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)
 .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,
 .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
 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
 .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