xmss - x modular screen saver
=============================

Version:  0.5 ALPHA - 94.01.06

Several months ago, I found out about the xautolock screen saver and attempted
to get it running under Linux.  With no success whatsoever:  after examining
the code, I came to the conclusion that its argument and resource parsing was
very badly botched.

At about the same time, I was experimenting with colormaps under X.  Since my
idea of experimenting is to throw code at it until I get it working :-) I
decided to combine the two into a single project:  to create an automatic
screen saver which used colormap manipulation.  This resulted in a pair of
programs, "xdim" which reduced the screen intensity, and a few days later
"xrss" which randomly changed screen colors after the fashion of early home
video games.

Of course, they were separate programs which shared a considerable amount of
code.  Killing the screen saver and starting a new one wasn't my idea of how
to switch between the two, so I decided to combine them.  This resulted in the
design of a different means of specifying resources, and the addition of
module-handling code.  Thus was "xmss" born.

I should have left out the "xlock" module, though; when I decided to release
it, I decided I should include a module which worked like xautolock.  But
"xlock" has been an extreme annoyance; I had to add a new status code to the
module management to allow the module to pass back the fact that the
subprogram had exited, since "xmss" otherwise might think the screen was still
supposed to be blanked, degrade into the emergency-backup "blank" saver, and
stay that way.  Or correctly not degrade, but incorrectly not realize that
there really had been an unblank, and leave the screen on (great screen saver,
there...).

"xmss" is still in development.  After looking at the original version, which
didn't support resource classes at all, I came up with the current kluge
involving the "Saver" class.  Then I wrote the section of xmss_module.man
which covered adapting existing modules and suggested a resemblance to
subclassing... and realized that I was using modules as instances instead of
as classes.  This resulted in the bogus "Saver" superclass.  A future rewrite,
when I get the time, will reorganize it to treat the modules as classes with
instances.  This will not only clean up the "Saver" idiocy, it will also allow
multiple instances of a given class (most useful for "xlock", but I want to
write a simple animated-XPM saver at some point and that will also want
multiple instances to be most useful).

Feel free to contribute bugs reports, portability concerns, and even the
occasional module.  :-)

Brandon S. Allbery
bsa@kf8nh.wariat.org
January 6, 1994
