The configuration dialog only shows screenhacks that are either hardcoded
inside the xscreensaver binary, or manually entered into ~/.xscreensaver.
This means there is no easy way to make packages that provide additional
screenhacks.

Currently there's the rss-glx package which has to use an awful hack
to make the screensavers work: rss_glx-install, a script that has to be
run by *every* user on the system manually. Not user friendly at all!

The package should instead do what is suggested by one way of interpreting
/usr/share/xscreensaver/config/README:

It shouldn't just read the xml files at runtime, but also the contents
of the directory, so that additional screenhack packages can just dump
their xml file into /usr/share/xscreensaver/config and just work.

No, that's what the /usr/lib/X11/app-defaults/XScreenSaver file is for.  (Exact directory may vary. Consult your doctor.)

That does, indeed, sound like a very dumb way to do it. The maintainers of that package should do something less dumb.

The XML directory is used only by the "xscreensaver-demo" program, the GUI.

The app-defaults file is used by both "xscreensaver" and "xscreensaver-demo".

I am facing the same problem. After *many* hours of trying to
understand why nor xscreensaver, nor xscreensaver-demo was not reading
my XML file, I finally realised that only the global config file and
the user config file are checked to get a list of hacks.

Now, as a maintainer, how I am supposed to add a hack to the list?
Surely not editing a conffile from other package in postinst, as that
is not permitted by the Debian Policy. Is there any other way to do
this?

The policy has good reasons for that. Although, what you suggest could
be a solution, the problem is migrating current configurations where
that file has been locally modified.

As a side note, I would like to suggest you to document this somewhere
in the upstream source, as I think most people will assume that the
XML files are enough, and spend a lot of time trying to understand why
XScreensaver is not reading them.


José, do you think it is possible to implement Jamie's suggestion?
There aren't many xscreensaver hacks in the archive, but they will
benefit from this, and it would make a lot easier to package new
hacks...

It's documented in the man page... If you think it's unclear send me a change.

I guess you could just regenerate the programs section of the app-defaults file from the existing XML files if you wanted. Then postinst could run the "rebuild" script you've added to the xscreensaver package.

I don't think that modding the xscreensaver daemon itself to scan and read the entire directory of XML files is a great idea, because that's a lot of file I/O, but maybe it doesn't matter.

The daemon itself currently contains no XML parser and I want to keep it that way.

Policy aside, that is how you do it.  I don't see another way.

If ~user/.xscreensaver lists hacks A, B and C, and you want them to also see D, you need to put D in the system-wide /.../app-defaults/XScreenSaver file.

I guess you could modify both packages to install their version as XScreenSaver-pkgname and then have postinst for both packages treat the app-defaults file as a generated file from whatever wild carded files it finds. Maybe that would work as a loophole for whatever the policy is.

On 12/06/2011 09:26 PM, Martín Ferrari wrote:
[...]

Sure Martín, just send me a patch. We maintain everything on
git.debian.org/git/collab-maint/xscreensaver.git

Send it on email or just let me know from where make pull.

Cheers!