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). I will also remove the "enabled" flag in favor of "random" instance resources specifying lists of module instances. Anyway, on to the features: * automatic screen saver invocation based on idle keyboard/pointer * "hotspots" and "coldspots", defined as arbitrary X geometry specifications, specified by the user on the command line or as resources; hotspots force immediate blanking, coldspots prevent blanking * a hotkey which highlights the user-defined hotspots and coldspots with user- specified colors * a choice of modules: "dim", "2600" (resembles the screen saver of a certain once-popular home video game), "xlock" (runs a user-specified external program), "random" (randomly chooses one of the others when invoked). * a public module definition, including a manpage on module writing Now all I need is module overlaying a' la a certain commercial screen saver, but I don't think it'd work with "xlock" too well... I also need more modules. I plan to write some more, but what's the point of a *public* module definition if nobody else writes modules? Let's see some creativity out there! Feel free to contribute bugs reports, portability concerns, and even the occasional module. :-) Brandon S. Allbery bsa@kf8nh.wariat.org January 6, 1994