[14653] in Athena Bugs
Re: sun4 8.0I: xscreensaver
daemon@ATHENA.MIT.EDU (Mark Eichin)
Tue Sep 10 00:08:23 1996
To: Greg Hudson <ghudson@MIT.EDU>
Cc: bugs@MIT.EDU
In-Reply-To: "[14620] in Athena Bugs"
From: Mark Eichin <eichin@MIT.EDU>
Date: 10 Sep 1996 00:08:12 -0400
FYI -- xautolock, ftp.x.org:/contrib/applications/xautolock.pl10.tz,
seems to do most of the work. (Not sure if any athena platforms
support the Xidle extension...)
quoting from the README...
HOW IT WORKS
============
If xautolock has been compiled to support Xidle, it first tries to
find out whether the X server also supports Xidle. If it does,
xautolock will periodically call xidle to determine the elapsed time
since the last input event, and will then base its actions upon that.
In the absence of Xidle, when it starts executing, xautolock
traverses the window tree, selects SubstructureNotify on all windows
and adds each window to a temporary list. About +- 30 seconds later,
it scans this list, and now asks for KeyPress events. However, it
takes care to interfere as little as possible with the event
propagation mechanism. This is the reason for the delay between the
moment xautolock learns about a new window (and consequently asks for
SubstructureNotify events) and the moment it asks for KeyPress
events. Whenever a new window is created by an application, a similar
process takes place. In contradiction to what many people believe,
this scheme does not cause a noticeable overhead.
In addition, xautolock periodically issues a QueryPointer request in
order to find out whether the pointer has moved and implement the
"corners" feature as decribed in the man page.
If nothing happens within a user-specified period of time, xautolock
will fire up a program which is supposed to lock the screen. While
this program is running, xautolock itself remains on the look-out for
user interaction.
