I always asked myself why do we have too many screensaver tools, all of them doing the same thing, like xscreensaver, kscreensaver, gnome-screensaver or xlock; why we don't have one, a good one and numerous frontends for it. Wouldn't be so much simple?
I'm not sure who came first after xlock, but reading
FAQ, situation between them (a.k.a. cooperation) is not very
good. I don't know how gnome-screensaver works, but kscreensaver
(at least one from 3.5.x series) is a wrapper around xscreensaver
with own ways of doing things, which makes XScreenSaver author
After reading those answers on FAQ, you would, as any
reasonable person in FOSS worls, starting to ask why those damn
KDE/GNOME guys didn't use what already was given to them? Why do
they have to invent the wheel all over again filling our hard
drives with programs doing same stuff just with different names?
But, it turns out XScreenSaver is not perfect and seems
author does not care about it (actually, there is no such a thing
as perfection in software, but everyone strives to it). I'm talking
here about perfection towards developers, those who want to utilize
XScreenSaver with own frontends and addons.
Documentation about this is, simply said, a zero.
XScreenSaver is split between daemon and GUI frontend, and the way
how they communicate is buried deep in the code, so if you want to
discover it, well... go for it. Everything from seeing is daemon is
started, sending preview hacks (these are those stuff you are
seeing on the screen after screensaver is invoked) and on demand
blanking, quitting and etc. is up to you to figure out.
Maybe author didn't want to expose own "
messaging API", but many
programs can benefit from it. For example, media players can
temporarily halt daemon when is started or when those visual
effects are played within the song. Yes, some of them (at least I
know about Mplayer and Xine) detect it and do the right thing, but
how about something more than that?
Let say you want to tell daemon to use specific hack as
default one, store own preferences and similar. Yes, these are
tasks for own fronted and XScreenSaver is not very fronted
friendly. So, what is the solution? Doing the same thing
XScreenSaver does; again reinventing the wheel.
During last few days, I was working on
improved fronted we had before. I tried to go beyond a major
limitation it had before: detecting a new hacks or to be
xscreensaver version agnostic.
To be precise, previous version (older name was
esvrconf) had builtin list
of hacks, copied from one of the older xscreensaver versions and...
you know how what happens: thins are changed, options are
added/removed and would be nice if
addopt to these. Also, one of the goals was to read/write directly
in ~/.xscreensaver file (where options are stored) so, besides
daemon, xscreensaver own GUI fronted could cooperate nicely.
So, did I manage to achive given? Most of it.
happily read user .xscreensaver file and display needed stuf. If
that file does not exists, it will scan for hacks and their config
files in usual places and re-generate it. Of course, it will
contain only options it needs; for more options you'll still have
One option I'm not going to implement, at least now, is
"refreshing for a new hacks" (didn't have a better name). For
example, if you add a new hack (in usual hack directory) and user
.xscreensaver exists without it, it will not be seen. To see it,
you'll have to remove that .xscreensaver file and let
the rest. Not so complicated :P
And one of the properties I'm very happy about is merging
with existing user config file: e.g. you have config file generated
filled with all needed and uneeded stuff) and after you change
changed options will be updated, preserving those written by
xscreensaver-demo. At the
end, everybody should be happy :)
Now, the only issue left is to finalize GUI look (and test
for hidden bugs). Currently it looks like improved
esvrconf, but there is a
few places for more enhacements. We will see...