Security plug don't support light-locker [$50]

[Cody Garver]

Looks like privacy plug has only one affected file, src/LockPanel.vala. There are three things to take into account:

(a) enabling/disabling locking
(b) whether or not to lock on suspend
(c) inactivity delay for activating the lock screen

[Danielle Foré (danrabbit)]

https://www.bountysource.com/issues/2618320-plugs-don-t-support-light-locker

[adiunix (vadithya1993)]

Guys Im sorry I did something.
Im new here

[Robert Roth (evfool)]

I would work on this, but can't find the light-locker keys we should use.
I have checked the trusty gnome control center code from launchpad, and it seems they are still using the gnome keys, and haven't found anything light-locker related in my dconf settings either. What am I missing?

[Cameron Norman (cameronnemo)]

Maybe take a look at XFCE code. IIRC, at least in Debian, XFCE uses lightdm and light-locker. I was unable to find any sort of dconf key or config file. Reading the light-locker source, it seems as though it has no source of configuration other than command line options D :

[Cameron Norman (cameronnemo)]

I asked the Debian XFCE maintainers, and they said no. Perhaps we will have to add it ourself and then throw the new upstream version in the PPA. The only other option (that I can think of) would be to edit the Exec= line in the autostart entry, but that may be difficult (we would also have to restart light-locker after editing those settings).

What should be simple is to enable/disable screen locking by playing with light-locker's desktop entry's Hidden= key (or should we add light-locker to Cerbere's list of processes and remove or add it based on whether the user wants a lock screen).

[Cameron Norman (cameronnemo)]

Sorry, I meant that the XFCE guys said there was no config or dconf key.

[Cameron Norman (cameronnemo)]

Hey, so the power plug seems to only look at org.gnome.settings-daemon.plugins.power, not a gnome-screensaver key. Are you sure that switchboard-plug-power is affected?

[Cameron Norman (cameronnemo)]

Looks like privacy plug has only one affected file, src/LockPanel.vala. There are three things to take into account:

(a) enabling/disabling locking
(b) whether or not to lock on suspend
(c) inactivity delay for activating the lock screen

Enabling or disabling locking can be done by disabling the autostart entry for light-locker, but lock on suspend requires playing with command line options. AFAICS, light locker has no way to do the timeout itself. It can lock on screensaver, and the screensaver can be on a timeout, though.

[Robert Roth (evfool)]

Looking at light-locker-settings[1] (a simple tool to configure light-locker) it does stop the existing light-locker process and restart it with the new set of command line options. This would be overkill IMHO from an instant-apply GUI, as after changing any of the components, you would have to find the process, stop it, build the new argument list and restart the process.

The best would be to have gsettings for this, so I agree with cameronnemo that we should add support for gsettings and get that accepted upstream, and then use those settings in the privacy plug.

[1] http://bazaar.launchpad.net/~light-locker-settings-team/light-locker-settings/trunk/view/head:/light-locker-settings/light-locker-settings.py

[Robert Roth (evfool)]

After a discussion with an upstream maintainer, it seems like there's a half-finished DBus interface [1] to finish, so if we manage to do that (or if the maintainers do that, but they seem to be busy atm), gsettings is not necessary, we could use the dbus service for setting whatever we want.

[1] https://github.com/the-cavalry/light-locker/tree/dbus-service

[Danielle Foré (danrabbit)]

Confirmed with Robert on Slack that the DBus interface is indeed finished and we're no longer blocked by upstream here

[Cody Garver (codygarver)]

I have imported the latest version of light-locker to Freya, it contains the new DBus interface we need

[Cameron Norman (cameronnemo)]

@Cody: Err. I am not sure a D-Bus interface is what we want here. We want a gsettings schema. Luckily someone is doing work on it right now: https://github.com/bluesabre/light-locker. I have that branch installed on my computer currently and it works fine. I also started a branch that uses the gsettings schema being developed (it is linked to this bug), however it has a lot of removed features (simply because light-locker is not up to the task) and obvious UI bugs.

I filed an issue/question for the big major regression from gnome-screensaver (https://github.com/the-cavalry/light-locker/issues/41), however I think it might not be fixed for Freya.

[Cody Garver (codygarver)]

We could import that fork but I don't like that bug you linked

[Cameron Norman (cameronnemo)]

@codygarver So there is this little thing called xautolock that can launch a command (we would want `dm-tool lock` in this case) on an inactivity timeout. The thing is the timeout can not be reset while xautolock is running without manually killing the daemon then starting it up again. Also it has a maximum of a 60 minute timeout.

I will try to get the plug coded ASAP using this.

[Cody Garver (codygarver)]

We did it