xscreensaver autostarted in KDE session

See also xscreensaver (5.10-6) unstable in Debian:

http://packages.debian.org/changelogs/pool/main/x/xscreensaver/current/changelog

This bug was fixed in the package xscreensaver - 5.10-3ubuntu3

---------------
xscreensaver (5.10-3ubuntu3) lucid; urgency=low

  * Removing autostart from xdg, is now on /usr/share so user can copy it if
    wants autostart (LP: #554069)
 -- Alessandro Ghersi <email address hidden> Sat, 10 Apr 2010 22:28:57 +0200

I don't believe I agree with this change. This means that xscreensaver will never start automatically when it's installed. What about systems that don't use gnome-screensaver or kde's screensaver, and rely on xscreensaver?

They have to go and *manually* enable xscreensaver?

<apachelogger> it probably would be best to have the desktop file say NotShowIn=KDE;GNOME; I suppose
<lex79> yes
<apachelogger> and I think that the desktop entry spec should be enhanced to take running processes into account
<apachelogger> so you can go: show the knm menu entry UNLESS knm is running, same for klipper and krandrtary, and same here
<apachelogger> run that nice xscreensaver unless another screensaver is running

I do however believe that the currently applied fix is proper and good seeing as it is what is applied in Debian. Also there is no 100% proper solution to this anyway, even a notshowin would not take into account that you can run KDE and GNOME without their associated screensaver implementations.

Just because it was the current thing that is applied in Debian doesn't mean it's proper.

This will have broken any XFCE installs - Xubuntu and Mythbuntu are both affected.

Agreed. Please revert and fix the real issue - that xscreensaver gets installed for whatever reason on Kubuntu upgrade from Karmic to Lucid.

Furthermore, in the future, changes that you know or suspect will affect other flavors of Ubuntu should be discussed first on ubuntu-devel before being made.

FWIW, this doesn't really affect Xfce, as /etc/xdg/xfce4/xinitrc will start xscreensaver anyway, and is executed before the autostarted desktop files.

Cody, that is confusing. First you say that we shall revert and fix the real issue and then you describe the real issue as "that xscreensaver gets installed for whatever reason on Kubuntu upgrade from Karmic to Lucid."

Unless I am confusing things here, then the autostart was only introduced in October and removed less than half a year later (January or Februar, cant remember) because it apparently was disliked by a large enough portion of Debian users to justify partially reverting this autostart addition (in the sense that it was moved to opt-in). So clearly XFCE and "systems that don't use gnome-screensaver or kde's screensaver, and rely on xscreensaver" had a system in place to start the xscreensaver LONG before this autostart desktop file was added.

So the fix to the real issue, you demand, is the very same that you want reverted, since the problem only arose since Debian added that desktop file in October.

And here is my most personal view on the autostart business altogether. The wm/desktop environment should decide, and if the wm/desktop enviornment does not, then the user must do it for themselves. At no rate should we "enforce by assumption" that a KDE users will use kscreesnaver, or that a GNOME user will use gnome-screensaver, and that a XFCE user uses xscreensaver. Let alone systems where you find a mixture of them, what should be the preferred action then? Start all of them? Start screensaver X unless desktop file processing component A is in notshowin? What if app B invokes a desktop file processing component C that is not listed in notshowin, will it start screensaver Y? What if I dont want screensavers at all, but some silly metapackage depends on either?
From my POV opt-in is the only sane approach, whereas desktop's or default installations might make assumptions about what the user might want to use, they should be opt-out. So a user might opt-out of kscreensaver and opt-in xscreensaver. Good fun with that if the desktop file contains a NotShowIn=KDE; and an update via -updates lands!

I agree with Mario and Cody: installing xscreensaver should configure itself to autostart.

It seems that if a user uses KDE screensaver, it is useless to have the xscreensaver package installed. KDE can display xscreensaver "hacks" too, with the help of kscreensaver-xsavers* packages, but this only requires xscreensaver-{data,gl}{,-extra}, not xscreensaver. So for these users, simply removing xscreensaver would solve the problem.

KDE users who have KDE screensaver disabled and want to use xscreensaver just need to install xscreensaver, if the package sets up the daemon to autostart.

Although removing or installing packages can take more time than deleting or copying a desktop file, the former approach seems more elegant to me.

The only missing "feature" would be the ability to keep xscreensaver installed but not autostarted. I think this would be less commonly needed (if kubuntu-desktop and ubuntu-desktop do not automatically install xscreensaver), and the user can still manually delete the desktop file to accomplish this. Or there could be a config file in /etc/defaults for whether xscreensaver is actually autostarted...

Currently XFCE might be "hard coded" to start xscreensaver, but that doesn't seem to be a good solution either.

There are systems (I recall the clients at my university) where you've got all of KDE, Gnome and XFCE installed. And three implementations of a sceensaver. Only one of them should autostart of course. So a decision based on an installed packet doesn't work.

If XFCE is broken my a removal of the xscreensaver autostart entry (which doesn't seem the be the case), then XFCE needs a GUI to enable the screensaver and copy the item to your personal autostart folder. But not a global all-overriding autostart entry. If you don't use a DE but only a WM, I guess you know how to edit your xinit file.

So unless anybody's system is horribly broken by a revert back to a state which worked for ages, could you please stop commenting on this bug an spamming my inbox? :) If you think the decision was wrong, please open a new bug/wish (which will probably be closed instantly).

By that logic we should remove the autostart entry for the gnome screensaver
too. I'm sure lots more people would start complaining if
gnome-screensaver's autostart entry was removed.

On Sun, Apr 11, 2010 at 14:17, Malte S. Stretz <email address hidden> wrote:

> There are systems (I recall the clients at my university) where you've
> got all of KDE, Gnome and XFCE installed. And three implementations of a
> sceensaver. Only one of them should autostart of course. So a decision
> based on an installed packet doesn't work.
>
> If XFCE is broken my a removal of the xscreensaver autostart entry
> (which doesn't seem the be the case), then XFCE needs a GUI to enable
> the screensaver and copy the item to your personal autostart folder. But
> not a global all-overriding autostart entry. If you don't use a DE but
> only a WM, I guess you know how to edit your xinit file.
>
> So unless anybody's system is horribly broken by a revert back to a
> state which worked for ages, could you please stop commenting on this
> bug an spamming my inbox? :) If you think the decision was wrong,
> please open a new bug/wish (which will probably be closed instantly).
>
> --
> xscreensaver activated on kubuntu after upgrade to lucid
> https://bugs.launchpad.net/bugs/554069
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Mario Limonciello
<email address hidden>

Fortunate enough that gnome-screensaver will only autostart in GNOME then.

Since there seems to be no intuitive way to stop xscreenserver in the Kubuntu settings, it is very confusing for a user that the screensaver cannot be disabled. I believe the screensaver functionality must be de-coupled such that there are no side-effects to another desktop only because there are more than one desktop installed.

A solution of xscreensaver not being installed with a Kubuntu (KDE) desktop fails to work correctly if other desktops are installed in addition to KDE. Furthermore, the xscreensaver daemon should actually be only be started when the xserver is started with a desktop which needs it. It needs to be started by the xserver, since otherwise the logout and login into another desktop does not satisfy both configurations chosen.

I suffer from this bug (and had created bug 550683 which I now believe to be a duplicate of the present one) since upgrading to Lucid.

I found myself running xscreensaver when it should not, and couldn't understand why it was now running.

I definitely think that xscreensaver should *not* auto-start just because its package is installed, it shoul be up to any given desktop environment to start it IF AND ONLY IF it is expected to run there.

It has nothing to do running when KDE or Gnome is in use.

I think this should be discussed on freedesktop.org and solved in XDG. IMO the wm's have to become more intelligent about what to start. We have to accept that one machine can have all kind of desktop environments installed and thus have a multitude of screensaver engines with autostart files around. One idea would be to have a category Screensaver or Unique-screensaver in the desktop files, and leave it to the wm to pick the one it prefers (or the user prefer) and only start one. Or a mechanism which permits a screensaver engine to detect another has already been started and politely refuse to start.

Meanwhile we could maybe ship the desktop file in lucid, but with "NotShowIn: KDE; GNOME;". This would at least take care of the default cases. But not the custom cases where Gnome users ditch gnome-screensaver, install xscreensaver and expect it to just work etc. Or if we need finer granulation for all the different DE's, a bunch of desktop files each with "OnlyShowIn: XFCE;" etc.

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://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

I am not sure why this is fixed released! if there is a fix, there should at least be a reference to it, or some kind of indication which package version has fixed it. This way nobody can understand what has been done to fix the problem, and afaik it is still existing on my laptop.

It's fixed because "xscreensaver is not autostarted in KDE sessions" any longer. Please file new bugs for other issues.