© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Swâmi, this bug should actually be fixed, so I doubt it is the very same issue.
Tormod, I do not think that "refusing to start" is a good idea, especially if Y is refusing because X is already running, but the user specifically configured Y to be the preferred choice. Also, after having thought about this a bit, I actually do not see any problem right now, as long as you don't have a global autostart file.
You have the KDE workspace, where the screensaver is built into the desktop shell itself, so isn't autostarted by anything but KDE. The user can turn off this screensaver implementation and add another implementation via the autostart configuration module as seen fit.
You have GNOME, where gnome-screensaver is autostarted via a global autostart desktop file that contains OnlyShowIn=GNOME; so again the workspace made a default choice of which the user can opt-out by usual autostart override means as defined by fdo. The user can then configure another implementation to autostart, as seen fit.
You have XFCE, where xscreensaver is autostarted via a script. This IMHO should indeed be changed, to a desktop file, but one that contains OnlyShowIn=XFCE; and is deployed by some XFCE package. Then everything said about gnome-screensaver applies here.
So you really don't need a new spec or enhancement to an existing one. Technically you'd just need to build a tool around those tasks and the user does not even have to care about removing autostart and adding another one, but just say "make xscreensaver my screensaver" and the tool would take the appropriate actions.
Using screen saver specifics in the desktop entry spec in regards to controlling autostart and all would however be nice... though, thinking about it...
Excuse me, but I always have ideas when trying to end a post ;)
The desktp menu specification as per fdo [1] already specifies a reserved category for screensavers. So building up on that one could create a new spec that defines the usage and management approach for screensavers, including autostart and all. So, I really doubt that state-awareness or refusing to start is necessary as long as one follows a clear plan, which could be defined via a spec.
[1] http://