On Sat, Apr 9, 2016 at 5:41 AM, Jamie Zawinski <j...@jwz.org> wrote: > I still think the root of the problem here is that the "zoom" xscreensaver > hack is marked as enabled in the .ad file, but it is not actually installed. > So the .ad file is wrong. Correcting it would fix this. I suppose it would be > possible to do that in a post-install script on the xscreensaver sub-packages. > > It would also work to make every entry in the .ad file be an absolute path > instead of relative. > > But I don't like the idea of forcing entries in the .ad file that are not > absolute paths to only run from a hardcoded directory.
I am also not so fond of the hardcoding. If the directory name could be overrun by a user setting it would have very acceptable though. On the other hand, we don't want to mess with users' or administrators' configuration files. Granted, if the system .ad is unmodified by the administrator, we can change it or modify by a script, but if the user has run xscreensaver and has his own configuration file we are not gonna touch it. "Breaking" it by not allowing all possible entries to run, would be more acceptable. We are after all tying everything down and installing the hacks to a very defined location. I think it is important that the stock setup works without issues, even if it means the rare experimental user gets one more hurdle for doing very specific customizations. Without turning it into gnome-screensaver :) Tormod
