Differences between version 4 and predecessor to the previous major change of xscreensaver(1).
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Tuesday, June 4, 2002 12:23:03 am | by perry | Revert |
| Older page: | version 3 | Last edited on Tuesday, June 4, 2002 12:23:03 am | by perry | Revert |
@@ -63,21 +63,21 @@
For the impatient, try this:
xscreensaver
-The xscreensaver-demo(1) program should pop up a dialog box that lets you experiment with the xscreensaver settings and graphics modes.
+The __
xscreensaver-demo__
(1) program should pop up a dialog box that lets you experiment with the xscreensaver settings and graphics modes.
__Note:__ unlike xlock(1), xscreensaver has a
client-server model: the ''xscreensaver'' program is a
daemon that runs in the background; it is controlled by the
-foreground xscreensaver-demo(1) and
-xscreensaver-command(1) programs.
+foreground __
xscreensaver-demo__
(1) and
+__
xscreensaver-command__
(1) programs.
!!CONFIGURATION
The easiest way to configure ''xscreensaver'' is to
-simply run the xscreensaver-demo(1) program, and
+simply run the __
xscreensaver-demo__
(1) program, and
change the settings through the GUI. The rest of this manual
page describes lower level ways of changing
settings.
@@ -240,11 +240,11 @@
Use the visual which supports the most colors. Note,
however, that the visual with the most colors might be a
-TrueColor visual, which does not support colormap animation.
+!
TrueColor visual, which does not support colormap animation.
Some programs have more interesting behavior when run on
-PseudoColor visuals than on TrueColor.
+!
PseudoColor visuals than on !
TrueColor.
__mono__
@@ -277,11 +277,11 @@
''class''
-where ''class'' is one of __StaticGray__,
-__StaticColor__, __TrueColor__, __GrayScale__,
-__PseudoColor__, or __DirectColor__. Selects the
+where ''class'' is one of __!
StaticGray__,
+__!
StaticColor__, __!
TrueColor__, __!
GrayScale__,
+__!
PseudoColor__, or __!
DirectColor__. Selects the
deepest visual of the given class.
''number''
@@ -356,17 +356,17 @@
it is already running, otherwise, will launch a new Netscape
looking at the ''helpURL''.
-__demoCommand__ (class __DemoCommand__)
+__demoCommand__ (class __!
DemoCommand__)
This is the shell command run when the ''Demo'' button on
the splash window is pressed. It defaults to
''xscreensaver-demo''.
-__prefsCommand__ (class __PrefsCommand__)
+__prefsCommand__ (class __!
PrefsCommand__)
This is the shell command run when the ''Prefs'' button
on the splash window is pressed. It defaults to
@@ -386,9 +386,9 @@
(Higher numbers mean lower priority; see nice(1) for
details.)
-__memoryLimit__ (class __MemoryLimit__)
+__memoryLimit__ (class __!
MemoryLimit__)
The sub-processes created by ''xscreensaver'' will not be
allowed to allocate more than this much memory (more
@@ -414,9 +414,9 @@
If this is true, then when the screensaver activates, the
current contents of the screen will fade to black instead of
simply winking out. This only works on displays with
writable colormaps, that is, if the screen's default visual
-is a PseudoColor visual. A fade will also be done when
+is a !
PseudoColor visual. A fade will also be done when
switching graphics hacks (when the ''cycle'' timer
expires.) Default: true.
@@ -486,9 +486,9 @@
If a line begins with a dash (-) then that particular
program is disabled: it won't be selected at random (though
you can still select it explicitly using the
-xscreensaver-demo(1) program.)
+__
xscreensaver-demo__
(1) program.)
If all programs are disabled, then the screen will just be
made blank.
@@ -553,10 +553,10 @@
colormap, but another works best if it has a 24-bit visual,
both can be accommodated:
- PseudoColor: cmap-program -root n\
-TrueColor: 24bit-program -root n\
+ !
PseudoColor: cmap-program -root n\
+!
TrueColor: 24bit-program -root n\
In addition to the symbolic visual names described above (in
the discussion of the ''visualID'' resource) one other
@@ -721,9 +721,9 @@
The background color used for the stdout/stderr text, if
__captureStderr__ is true. Default: Black.
-__bourneShell__ (class __BourneShell__)
+__bourneShell__ (class __!
BourneShell__)
The pathname of the shell that ''xscreensaver'' uses to
start subprocesses. This must be whatever your local variant
@@ -963,9 +963,9 @@
xscreensaver.c.
You can control a running screensaver process by using the
-xscreensaver-command(1) program (which
+__
xscreensaver-command__
(1) program (which
see.)
!!POWER MANAGEMENT
@@ -987,15 +987,15 @@
there is no ''~/.xscreensaver'' file yet.)
To change your power management settings, run
-xscreensaver-demo(1) and change the various timeouts
+__
xscreensaver-demo__
(1) and change the various timeouts
through the user interface. Alternately, you can edit the
''~/.xscreensaver'' file directly.
If the power management section is grayed out in the
-xscreensaver-demo(1) window, then that means that
+__
xscreensaver-demo__
(1) window, then that means that
your X server does not support the XDPMS extension, and so
control over the monitor's power state is not
available.
@@ -1109,9 +1109,9 @@
(If your system does not seem to be executing the
''Xsetup'' file, you may need to configure it to do so:
the traditional way to do this is to make that file the
-value of the ''DisplayManager*setup'' resource in the
+value of the ''!
DisplayManager*setup'' resource in the
''/usr/lib/X11/xdm/xdm-config'' file. See the man page
for xdm(1) for more details.)
@@ -1144,10 +1144,10 @@
running as a normal, unprivileged user.
For more information on the X server's access control
-mechanisms, see the man pages for X(1),
-Xsecurity(1), xauth(1), and
+mechanisms, see the man pages for __
X__
(1),
+__
Xsecurity__
(1), xauth(1), and
xhost(1).
!!USING GDM(1)
@@ -1171,9 +1171,9 @@
The easiest way to use ''xscreensaver'' on a system with
CDE is to simply switch off the built-in CDE screensaver,
and use ''xscreensaver'' instead; and second, to tell the
-front panel to run xscreensaver-command(1) with the
+front panel to run __
xscreensaver-command__
(1) with the
''-lock'' option when the ''Lock'' icon is
clicked.
@@ -1297,9 +1297,9 @@
This associates the VUE front panel ``Lock'' icon with the xscreensaver lock command.
!!ADDING TO MENUS
-The xscreensaver-command(1) program is a perfect
+The __
xscreensaver-command__
(1) program is a perfect
candidate for something to add to your window manager's
popup menus. If you use mwm(1), __4Dwm__(1),
twm(1), or (probably) any of ''twm'''s many
descendants, you can do it like this:
@@ -1329,9 +1329,9 @@
__3. Add the menu__
For mwm(1) and __4Dwm__(1), find the section of
-the file that says ''Menu DefaultRootMenu''. For
+the file that says ''Menu !
DefaultRootMenu''. For
twm(1), it will probably be ''menu
''. If you add a line somewhere in that
menu definition that reads
@@ -1345,9 +1345,9 @@
making a copy of the ''/etc/X11/fvwm2/system.fvwm2rc''
file. Then, add a menu definition to it:
- AddToMenu XScreenSaver
+ !
AddToMenu XScreenSaver
The Enlightenment window manager keeps each of its menus in a separate file. So, you need to create a file named ''~/.enlightenment/xscreensaver.menu'' with the contents:
@@ -1527,13 +1527,13 @@
The mwm(1) and olwm(1) 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
+!
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,
-__twm__ responds to the resultant __ColormapNotify__
+__twm__ responds to the resultant __!
ColormapNotify__
event by re-instaling the default colormap. Apparently,
__twm__ doesn't ''always'' 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
@@ -1543,14 +1543,14 @@
__Attention, window manager authors!__
-You should only call XInstallColormap(3) in response
+You should only call __
XInstallColormap__
(3) in response
to user events. That is, it is appropriate to install a
-colormap in response to __FocusIn__, __FocusOut__,
-__EnterNotify__, and __LeaveNotify__ events; but it is
+colormap in response to __!
FocusIn__, __!
FocusOut__,
+__!
EnterNotify__, and __!
LeaveNotify__ events; but it is
not appropriate to call it in response to
-__ColormapNotify__ events. If you install colormaps in
+__!
ColormapNotify__ events. If you install colormaps in
response to ''application'' actions as well as in
response to ''user'' actions, then you create the
situation where it is impossible for override-redirect
applications (such as xscreensaver) to display their windows
@@ -1605,9 +1605,9 @@
over a phone line) then the screensaver might not turn off
right away when the user becomes active again (the
ico(1) demo has this problem if being run in
full-speed mode). This can be alleviated by inserting
-strategic calls to XSync(3) in code intended for use
+strategic calls to __
XSync__
(3) in code intended for use
as a screensaver. This prevents too much graphics activity
from being buffered up.
@@ -1625,9 +1625,9 @@
Unfortunately, there is no way for xscreensaver itself to
override the interpretation of these keys. If you want to
disable Ctrl+Alt+Backspace globally, you need to set the
-''DontZap'' flag in your ''/etc/X11/XF86Config'' file.
+''!
DontZap'' flag in your ''/etc/X11/XF86Config'' file.
See the __XF86Config__(5) manual for
details.
@@ -1652,15 +1652,15 @@
Apparently there are some problems with XView programs
getting confused and thinking that the screensaver window is
the real root window even when the screensaver is not
-active: ClientMessages intended for the window manager are
+active: !
ClientMessages intended for the window manager are
sent to the screensaver window instead. This could be solved
by making xscreensaver forward all unrecognised
-ClientMessages to the real root window, but there may be
+!
ClientMessages to the real root window, but there may be
other problems as well. If anyone has any insight on the
cause of this problem, please let me know. (XView is an X11
-toolkit that implements the (quite abominable) Sun OpenLook
+toolkit that implements the (quite abominable) Sun !
OpenLook
look-and-feel.)
__MIT Extension and Fading__
@@ -1754,9 +1754,9 @@
__MIT-SCREEN-SAVER__), then it is possible, in rare
situations, for ''xscreensaver'' to interfere with event
propagation and make another X program malfunction. For this
to occur, that other application would need to ''not''
-select __KeyPress__ events on its non-leaf windows within
+select __!
KeyPress__ events on its non-leaf windows within
the first 30 seconds of their existence, but then select for
them later. In this case, that client ''might'' fail to
receive those events. This isn't very likely, since programs
generally select a constant set of events immediately after
@@ -1814,12 +1814,12 @@
http://www.jwz.org/xscreensaver/
!!SEE ALSO
-X(1), __xscreensaver-demo__(1),
-xscreensaver-command(1),
-xscreensaver-gl-helper(1), xdm(1),
-xset(1), Xsecurity(1), xauth(1),
+__
X__
(1), __xscreensaver-demo__(1),
+__
xscreensaver-command__
(1),
+__
xscreensaver-gl-helper__
(1), xdm(1),
+xset(1), __
Xsecurity__
(1), xauth(1),
xhost(1). ant(1), atlantis(1),
attraction(1), blitspin(1),
bouboule(1), braid(1), bsod(1),
__bubble3d__(1), bubbles(1), cage(1),
@@ -1842,9 +1842,9 @@
mountain(1), munch(1), noseguy(1),
pedal(1), penetrate(1), penrose(1),
petri(1), phosphor(1), pipes(1),
pulsar(1), pyro(1), qix(1),
-rd-bomb(1), rocks(1), rorschach(1),
+__
rd-bomb__
(1), rocks(1), rorschach(1),
rotor(1), rubik(1), sierpinski(1),
slidescreen(1), slip(1), sonar(1),
sphere(1), spiral(1), spotlight(1),
sproingies(1), squiral(1), stairs(1),
