On Sun, Dec 08, 2002 at 04:49:10AM -0500, Ari Pollak wrote:
> I suppose it would be possible to just include the binaries without
> touching the XScreenSaver config file but instead including
> instructions on including it on a user-specific basis, but I don't
> know how well the changes would transfer between XScreensaver
> versions.
Simplest hack I can think of: modify xscreensaver to be able to include
configuration files from the main configuration file and use menu to
register new screensavers. Something like:
?package(rss):needs=xscreensaver \
section="Come up with something for this field" \
title="Sky Rocket" \
visual="GL" \
command="/usr/lib/xscreensaver/skyrocket"
and there you go. You write a menu-method, run menu and you have an
up-to-date list of installed screensavers.
The problem is basically xscreensaver's configuration file. I have
considered a number of options to solve this. For example, you could
modify xscreensaver to read "info files" for each screensaver. In
those info files it would say, for example, if the program requires a
GL visual or not. But they could be more flexible than that. They
could document options, which could in turn be used for the
configuration part of xscreensaver. xscreensaver would then store the
list of "active" screensavers, instead of that ugly block in the config
file which mixes state with options with visuals with ...
It's dormant project of mine to take xscreensaver appart and write a
library that people can use to write screensavers for xscreensaver (and
whatever else -- but I'm only interested in xscreensaver really).
xscreensaver has some requirements (specific command line options,
specific behaviour regarding visuals, ...) and the code is _horribly_
duplicated across screensavers. The GL screensavers in particular
reinvent a (non-trivial to some degree) wheel way too often.
But this will remain dormant until ... well, I don't know for how long,
really. Perhaps someone will read this and go ahead with it :-)
--
Marcelo
