ede-screensaver-conf refresh

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 a few answers on XScreenSaver 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 pretty unsatisfying.

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 ede-screensaver-conf, an 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 ede-screensaver-conf could 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. ede-screensaver-conf will 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 to run xscreensaver-demo.

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 ede-screensaver-conf do 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 with xscreensaver-demo (and filled with all needed and uneeded stuff) and after you change something with ede-screensaver-conf, only 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...