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

Bug #1328786 reported by Cody Garver on 2014-06-11
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Switchboard Power Plug
Fix Released
Undecided
Robert Roth
Switchboard Security & Privacy Plug
Fix Released
High
Cameron Norman

Bug Description

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

summary: - Plugs don't support light-locker
+ Plugs don't support light-locker [$50]
Cody Garver (codygarver) on 2014-06-13
description: updated
adiunix (vadithya1993) wrote :

Guys Im sorry I did something.
Im new here

Changed in switchboard-plug-security-privacy:
status: New → Fix Released
Daniel Fore (danrabbit) on 2014-06-21
Changed in switchboard-plug-security-privacy:
status: Fix Released → New
Robert Roth (evfool) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in switchboard-plug-power:
status: New → Incomplete
status: Incomplete → New
Cameron Norman (cameronnemo) wrote :

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?

Changed in switchboard-plug-power:
status: New → Incomplete
Cameron Norman (cameronnemo) wrote :

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.

Daniel Fore (danrabbit) on 2014-06-24
Changed in switchboard-plug-power:
status: Incomplete → Fix Committed
assignee: nobody → Robert Roth (evfool)
status: Fix Committed → Fix Released
Changed in switchboard-plug-security-privacy:
status: New → Confirmed
milestone: none → freya-beta2
no longer affects: elementaryos
Robert Roth (evfool) wrote :

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) wrote :

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

Daniel Fore (danrabbit) on 2014-09-27
summary: - Plugs don't support light-locker [$50]
+ Security plug don't support light-locker [$50]
description: updated
Daniel Fore (danrabbit) wrote :

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

Cody Garver (codygarver) wrote :

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

Cameron Norman (cameronnemo) wrote :

@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) wrote :

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

Cameron Norman (cameronnemo) wrote :

@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.

Daniel Fore (danrabbit) on 2014-11-23
Changed in switchboard-plug-security-privacy:
status: Confirmed → In Progress
assignee: nobody → Cameron Norman (cameronnemo)
Daniel Fore (danrabbit) on 2015-02-01
Changed in switchboard-plug-security-privacy:
milestone: freya-beta2 → loki-beta1
Cody Garver (codygarver) wrote :

We did it

Changed in switchboard-plug-security-privacy:
importance: Undecided → High
milestone: loki-beta1 → freya-beta2
status: In Progress → Fix Committed
Daniel Fore (danrabbit) on 2015-02-09
Changed in switchboard-plug-security-privacy:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints