Bug 714413

They are kind of conflicting:

/etc/xdg/autostart/xscreensaver-autostart.desktop launches /usr/libexec/xscreensaver-autostart.

$ cat /usr/libexec/xscreensaver-autostart
#!/bin/sh

# Don't launch xscreensaver if gnome-screensaver
# is installed

if [ -x /usr/bin/gnome-screensaver ] ; then exit 0 ; fi

exec xscreensaver -nosplash

As soon as /usr/bin/gnome-screensaver is present, xscreensaver is not started. The only way to make really sure is to have the second file.

I need to think about this, maybe I will remove it from /etc/xdg/lxsession/LXDE/autostart.

(In reply to comment #1)

> I need to think about this, maybe I will remove it from
> /etc/xdg/lxsession/LXDE/autostart.

That's what I think too.
The user does not know about /etc/xdg/lxsession/LXDE/autostart, which starts:
$ ps aux |grep -i xscreen
jb        1609  0.0  0.2   5552  2068 ?        S    08:46   0:02 xscreensaver -no-splash

But the user knows how to control autostart apps thru:
Preferences - Desktop Session Settings
which corresponds to files in dir /etc/xdg/autostart/, and which is the right
thing to do.
If the user does that, then there would be a conflict with the above.

JB

Created attachment 505582 [details]
conflicting autostart config - recommended solutions

This is a continuation of the analysis and recommended solutions.
Note that this will apparently fix other errors/issues as well.
JB

Thanks for the analysis. 

- pulseaudio: I will investigate this, but as mentioned already, I cannot reproduce your problem. I wonder what starts pulseaudio if not /etc/xdg/lxsession/LXDE/autostart.

- pcmanfm: Is a core component of LXDE, it is required to show the desktop and to handle removable devices. It must be running all the time in daemon mode and if it crashes, it must be restarted. This is only possible through /etc/xdg/lxsession/LXDE/autostart but not in /etc/xdg/autostart/.
I am not going to make this one configurable because Fedora's LXDE would then be different from upstream's LXDE. This would need documentation and still lead to a high number of bugs - and I am the one to receive all the bug reports.

- xscreensaver: What about users who have installed both GNOME and LXDE? They will not be able to enable a screensaver, neither xscreensaver nor gnome-screensaver will work. This makes problems like bug 614608 worse.

(In reply to comment #4)
> Thanks for the analysis. 
> 
> - pulseaudio: I will investigate this, but as mentioned already, I cannot
> reproduce your problem. I wonder what starts pulseaudio if not
> /etc/xdg/lxsession/LXDE/autostart.

I would assume the lxpanel.
The Pulseaudio Volume Control is an lxpanel element (added thru Add/Remove
Panel Items), and so pulseaudio daemon may be a prerequisite.

> 
> - pcmanfm: Is a core component of LXDE, it is required to show the desktop and
> to handle removable devices. It must be running all the time in daemon mode and
> if it crashes, it must be restarted. This is only possible through
> /etc/xdg/lxsession/LXDE/autostart but not in /etc/xdg/autostart/.
> I am not going to make this one configurable because Fedora's LXDE would then
> be different from upstream's LXDE. This would need documentation and still lead
> to a high number of bugs - and I am the one to receive all the bug reports.

Yes, pcmanfm is part of LXDE, but perhaps not as essential as e.g. lxpanel to
be required to run at all times.

Do not panic - if you, and LXDE, and pcmanfm maintainer will agree with 
arguments below, you may become a hero :-)

Now, I do not have pcmanfm running:
$ cat /etc/xdg/lxsession/LXDE/autostart
@lxpanel --profile LXDE

The automount/autofs is not installed.
$ yum list "*autofs*"
Available Packages
autofs.i686             1:5.0.5-35.fc15                        fedora

Note: hal is retired (somehow still here).
# ps aux |grep -i hald
...
root      3612  0.0  0.1   4124   832 ?        S    16:53   0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec)

Note: the new kid in town is udisks, which provides a system message bus, and
relies on udev and kernel - udisks(7).
# ps aux |grep -i udisks
root      1234  0.0  0.3  23920  2988 ?        Sl   Jun19   0:14 /usr/libexec/udisks-daemon
root      1237  0.0  0.0   6236   272 ?        S    Jun19   0:12 udisks-daemon: polling /dev/sr0

I start pcmanfm to have it "ready" in background.
$ pcmanfm --desktop --profile LXDE &
[1] 3633
$ ps aux |grep -i pcman
jb        3633  7.3  1.1  97112  8364 pts/1    S    16:54   0:00 pcmanfm --desktop --profile LXDE

===========> my activities
- inserted cd-rom
===========> my activities

** (pcmanfm:3633): DEBUG: try automount
** (pcmanfm:3633): DEBUG: on_mount_action_finished

So, it seems that only with automount present and configured, a running
pcmanfm would be let know of new media (hd, usb, cd, etc) and perhaps pop up
on the desktop ?

But, in order to have this functionality, you do *not* need pcmanfm running
as a daemon in the background at all times !
The system is plugin-events sensitive (hal, udisks, udev, inotify), there are
also system buses like e.g. dbus and udisks available, and events like these
should be recognized by the system dynamically, and desktop should be
configurable to call (or not) pcmanfm as needed.

This should also work if you started pcmanfm ad hoc manually.

I think the pcmanfm maintainer would be more than happy to provide this
capability (the infrastrucuture is already there); it may be already
partially implemented and available.

If you look at:
  http://wiki.lxde.org/en/PCManFM_build_and_setup_guide
you see that it is already capable of:
  Setup Runtime Environment Correctly
  Runtime Dependencies
  ...
  gvfs and its dependencies (optional, but highly recommended)
    dbus and dbus-glib (required by gvfs)
    policykit-gnome (required for authentication for volume management)
  ...

There is no need to run pcmanfm constantly in the background and waste system
resources (we already have so many more or less "useless" daemons).
I noticed LXDE is lean and fast, and it should be kept that way - it is
a matter of a good design.

A candidate for LXDE request-for-enhancement ?

> 
> - xscreensaver: What about users who have installed both GNOME and LXDE? They
> will not be able to enable a screensaver, neither xscreensaver nor
> gnome-screensaver will work. This makes problems like bug 614608 worse.

Firstly, you should be concerned about LXDE working properly - it has a lot
of potential if improved, in particular if you consider that the alternatives
are slow, bloated, and suck inmany ways possible.

Secondly, if they decide for both (GNOME, LXDE) then let them decide which 
screensavers they want to run by configuring the DEs appropriately - see your
comment #1 - you will find a way to do it.

JB

> ...  
> > - xscreensaver:
> > ...
> > This makes problems like bug 614608 worse.
> 

The user is in control of her machine and its configuration !

The way it should work is this:
- no xscreensaver in /etc/xdg/lxsession/LXDE/autostart
- Preferences - Desktolp Session Settings governs behaviour
  xscrensaver-autostart control checked off - xscreensaver disabled
  xscrensaver-autostart control checked on  - xscreensaver started in background
     and behaving according to its configuration in
     Preferences - Screensaver - Blank After - Lock Screen After
- I have it configured  with Lock Screen After checked on, and every time
  I return from Suspend and Lock Screen After time was past due,
  the xscreensaver greets me with a login dialog.

So, it works as the user configured it.
And users should be told so every time they complain.

JB

(In reply to comment #6)
> > ...  
> > > - xscreensaver:
> > > ...
> > > This makes problems like bug 614608 worse.
> > 
> 
> The user is in control of her machine and its configuration !
> 
> The way it should work is this:
> - no xscreensaver in /etc/xdg/lxsession/LXDE/autostart
> - Preferences - Desktolp Session Settings governs behaviour
>   xscrensaver-autostart control checked off - xscreensaver disabled
>   xscrensaver-autostart control checked on  - xscreensaver started in
> background

But this does not work as soon as gnome-screensaver is installed. xscreensaver will not be started even if you enable it in Desktop Session Settings.

>      and behaving according to its configuration in
>      Preferences - Screensaver - Blank After - Lock Screen After

It's behaving according to the configuration anyway, regardless how it is started.

> - I have it configured  with Lock Screen After checked on, and every time
>   I return from Suspend and Lock Screen After time was past due,
>   the xscreensaver greets me with a login dialog.

But the people who filed that bug expect that the screen should be locked *every* time you wake up from suspend, even if time is not yet up.

(In reply to comment #7)
> (In reply to comment #6)
> > > ...  
> > - I have it configured  with Lock Screen After checked on, and every time
> >   I return from Suspend and Lock Screen After time was past due,
> >   the xscreensaver greets me with a login dialog.
> 
> But the people who filed that bug expect that the screen should be locked
> *every* time you wake up from suspend, even if time is not yet up.

Then, functionally, it is linked to suspend process. Is there any way to
"attach" xsreensaver to it ?
Perhaps take a look at:
/var/log/pm-suspend.log
and there is e.g.
/usr/lib/pm-utils/sleep.d/00powersave
How about making xscreensaver part of its execution (on suspend and resume) ?
JB

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > > ...  
> > > - I have it configured  with Lock Screen After checked on, and every time
> > >   I return from Suspend and Lock Screen After time was past due,
> > >   the xscreensaver greets me with a login dialog.
> > 
> > But the people who filed that bug expect that the screen should be locked
> > *every* time you wake up from suspend, even if time is not yet up.
> 
> Then, functionally, it is linked to suspend process. Is there any way to
> "attach" xsreensaver to it ?
> Perhaps take a look at:
> /var/log/pm-suspend.log
> and there is e.g.
> /usr/lib/pm-utils/sleep.d/00powersave
> How about making xscreensaver part of its execution (on suspend and resume) ?
> JB

The above is a possible solution.

BUT, I do not think that this should be a permanent feature of LXDE experience.
I agree with your opinions there that this is about *customization* :
https://bugzilla.redhat.com/show_bug.cgi?id=614608#c5
https://bugzilla.redhat.com/show_bug.cgi?id=614608#c13

So, if the above would work, then you can suggest it to SUSE bug filer https://bugzilla.redhat.com/show_bug.cgi?id=614608
how they can accomplish that if they wish to customize to achieve their effect.

You may want to place it in LXDE wiki as a customization tip for everybody as
well.

JB

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping