GNOME Bugzilla – Bug 644400
screen is locked on idle even when disabled in control center
Last modified: 2012-09-30 12:07:20 UTC
On my laptop, the "Screen" panel in the control-center, I have "Lock" set to OFF. When the screensaver kicks on however, that setting is ignored and the screen is locked anyway.
This is with: gnome-screensaver-2.91.91-1.fc15.x86_64 control-center-2.91.91-1.fc15.x86_64
Looking at the code, it seems that gnome-screensaver is not monitoring its settings at all. Its just loading them once. Restarting gnome-screensaver after changing the switch makes it pick up the new setting.
Disregard comment 2
Definitively see this too, tough
I was seeing this too but only when the screensaver was started at login. If I kill it and run it again from the command line with --debug I'm not able to reproduce.
The screensaver seems to be ignoring all gsettings changes when run at login. If I restart from a terminal everything works as expected. Matthias, any idea why this might be?
My only idea is that activation vs autostart might play into it. Try removing the service file and see if it makes a difference ? (I don't really know _how_ it would make a difference...)
commit c0ad16d66f3d547a9a45818bc193a34c428e977b Author: William Jon McCann <jmccann@redhat.com> Date: Sun Mar 20 21:09:30 2011 -0400 Remove daemonizing It isn't needed and it breaks things like GSettings apparently. https://bugzilla.gnome.org/show_bug.cgi?id=644400
Reading the commit message and this report I do not see how this is »apparently«. Additionally, how do I know `gnome-screensaver` is done loading now? The bash code lock_prog="gnome-screensaver" lock_cmd="gnome-screensaver-command --lock" if command -v -- $lock_prog >/dev/null 2>&1; then $lock_prog & # It does not matter if it is already running. $lock_cmd >/dev/null 2>&1 && exit fi fails, because it looks like when running `gnome-screensaver-command --lock` GNOME Screensaver is not fully up yet.