Created attachment 6582
light-locker support patch
In Bug #3770 xflock4 was fixed to properly lock with xscreensaver, gnome-screensaver and more. But `light-locker` support has not been added. And I see light-locker was specifically geared towards XFCE.
Basically just a line needs to be added:
"light-locker-command -l" next to the `gnome-screensaver-command --lock` command.
That is already used in ubuntu but looks like not ported to official version:
Attaching a patch if that makes it any simpler for you.
I think it is better to leave the `gnome-screensaver-command -lock` as last checked screensaver. If gnome-screensaver is installed, the command will start gnome-screensaver daemon, even if it is not running, if light-locker is not running; if light-locker is running it seems to do the same as `light-locker-command -l`, which is odd.
@Jarno Suni, I am fine with your suggestion to leave gnome last. I don't have it installed and didn't know it launches daemon when not running.
wrt why it does the same, it is not so strange because light-locker is a fork of gnome-screensaver. So I assume they use similar mechanism to invoke daemon. But if gnome-screensaver is not installed, then it cannot be used to invoke light-locker. So we still need to try the light-locker-command.
Thank you for trying that out!
Unfortunately it may not work properly even if you put light-locker-command before some other check in current form: If light-locker is installed, but not running, `light-locker-command -l` will exit with 0 and thus the script exists, too, but does not do what it is asked for.
In Bug #3770 I presented a way to detect, if a daemon is running, but it was not accepted for some reason, maybe portability. Actually the behavior of gnome-screensaver was reported as bug in 2010 and was reported to be fixed then, too: https://bugzilla.gnome.org/show_bug.cgi?id=629740, but the bug still exists in latest Ubuntu's (15.10) gnome-screensaver 3.6.1.
As for light-locker, the check could use command `light-locker-command -q` which seems to display
** Message: Locker is not running!
if the daemon is not running; that of course requires that light-locker is installed.
Note, that the message mentioned in the previous comment is sent to standard error, and the output to standard output seems to be empty string.
I made a bug report about light-locker's behavior: https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1536238
And about gnome-screensaver's behavior, as well: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1536237
After all I hated light-locker as it blocks me from using any text tty as it kicks in everytime I switch to text console. So decided to switch back to gnome screensaver. What I see is that in fact gnome-sceensaver does *not* launch by itself if not started already.
What version did you tested with? Mine is:
gnome-screensaver 3.6.1 (fedora 23)
Xubuntu 15.10, here light-locker does not block text ttys.
Where does light-locker 3.6.1-7ubuntu1 come from? Upstream I see latest version 1.7.0. Also are you sure that gnome-screensaver is not running in the background and you actually use gnome-screensaver instead of light-locker?
Another thing is that I have dm-lock and I suspect non-lightdm setup may behave differently from any other display manager.
Sorry, light-locker package has version 1.6.0-4ubuntu1
gnome-screensaver was not running in background. I am using lightdm.
This bug is duplicate of Bug 11785.
A year later, still no official patch released...
Patch originally posted by the creator works fine, though I add the light-locker-command as the first locker.
Will this ever reach to the official release? (no reason for it not to as it's an extremely simple patch and light-locker is very widely used due to its lightweight nature)
My attachments for Bug 10217 provide better ways to detect which screensaver is running. Note that for it to work with lockers, too, you need to have both xflock4 and command-dpms present, the latter in /usr/local/bin or in path output by command 'getconf PATH'.
*** This bug has been marked as a duplicate of bug 11254 ***