Bug#344559: Including .desktop files

Sam Morris sam at robots.org.uk
Wed Aug 15 14:25:03 UTC 2007

On Wed, 2007-08-15 at 16:04 +0200, Sven Arvidsson wrote:
> On Wed, 2007-08-15 at 14:41 +0100, Sam Morris wrote:
> > I think that the best way to solve this would be to have xscreensaver
> > ship the .desktop files along with the hacks themselves. The .desktop
> > files can be generated automatically as part of xscreensaver's build
> > process, so the maintenence burden should be slight.
> If you do, it would probably be best to split the package and only ship
> a select few of the screensavers by default, similar to how Ubuntu does
> this; http://packages.ubuntu.com/gutsy/x11/xscreensaver-data

This might not be necessary: the fdo menu spec allows us to specify
which screensavers are enabled by default. Although I don't know if
there is a way for the user to enable any that we have disabled;
currently I believe the enable/disabled status is reflected by
hiding/showing screensavers in g-s-preferences rather than by greying
them out or giving them a checkbox.

I agree that it would be cleaner to split xscreensaver into separate
xscreensaver, xscreensaver-hacks and xscreensaver-hacks-gl packages, but
now that xscreensaver no longer ships a .desktop file for its
preferences program, that's no longer a pressing concern :)

> If not, we should probably not install the xscreensaver hacks by default
> in GNOME.

If (as I suspect) the user can't override a default menu file that we
might ship from the GUI (rather than creating their own menu file in
~/.config) then I think it is perfectly sensible to have
gnome-screensaver merely Suggest xscreensaver (and xscreensaver-gl and

My main concern here is really to prevent screensavers that have been
known to show controvertial content (webcollage, the RSS reader one,
etc.) from being enabled without the user's consent. Ideally we should
display some kind of "screensavers that display third party content may
contain unexpected porn and nazi propoganda and get you in trouble"
warning when these hacks are enabled, but this is really a discussion
for a separate bug. :)

Sam Morris <sam at robots.org.uk>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20070815/e2e829b1/attachment.pgp 

More information about the pkg-gnome-maintainers mailing list