After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331754 - gconf settings for locking not clear and do not cover all possible options
gconf settings for locking not clear and do not cover all possible options
Status: RESOLVED FIXED
Product: gnome-power-manager
Classification: Deprecated
Component: general
SVN TRUNK
Other Linux
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks: 331717
 
 
Reported: 2006-02-19 09:47 UTC by Jaap A. Haitsma
Modified: 2006-02-19 16:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jaap A. Haitsma 2006-02-19 09:47:03 UTC
As explained in bug 331164

lock_ac_lid
lock_battery_lid
lock_button_suspend
lock_sleep_idle

do not cover all options. A better solution would be to do it by action

So:

lock_on_blank_screen
lock_on_hibernate
lock_on_suspend

This covers all possible cases. Only possible issue with this that you cannot have different behaviour when you are on battery or on ac. But let me try to explain that that is not really an issue.

For hibernate and suspend that is not an issue anyway. I don't see anybody wanting different locking behavior.

So now for docking station

If the laptop is already in the docking station we won't get a close lid event. So it's not an issue

If it's not in we close it and before inserting it in the docking station we need to unplug the AC power adapter, because the laptop will receive power from the docking station. At least with the DELL docking stations I know. So I think it's also a non-issue here.

Correct??

If not then we should have:

lock_on_blank_screen_on_ac
lock_on_blank_screen_on_battery
lock_on_hibernate
lock_on_suspend
Comment 1 Richard Hughes 2006-02-19 10:41:26 UTC
I'm not sure this is fine grained enough. The whole rationale for having custom settings is so that we can specify *exactly* what we want the locking to do.

Jon, what is your view? Jaap, I am willing to change the policy if you are sure you can cover all use-cases. I'll cc in Daniel and get his view also.

Richard.
Comment 2 Jaap A. Haitsma 2006-02-19 11:05:06 UTC
My whole point is that the current setup of gconf keys in CVS does not cover all possibilities.
For example I cannot know what happens when I choose hibernate from the panel menu.

The set:
lock_on_blank_screen_on_ac
lock_on_blank_screen_on_battery
lock_on_hibernate
lock_on_suspend

covers all possibilities but as I argue in my previous comment lock_on_blank_screen_on_ac and lock_on_blank_screen_on_battery are not really necessary to seperate.
Comment 3 Richard Hughes 2006-02-19 11:24:18 UTC
> For example I cannot know what happens when I choose hibernate from the panel
menu.

lock_on_menu_click

Okay, I get your point. :-)

lock_on_blank_screen
lock_on_hibernate
lock_on_suspend

are probably enough.

Got a patch or want me to do some work?

Richard.
Comment 4 Jaap A. Haitsma 2006-02-19 11:28:32 UTC
Haven't got a patch. Feel free to go for it ;-). I'll come up with a patch for the  other stuff we are discussing currently
Comment 5 Richard Hughes 2006-02-19 16:37:49 UTC
2006-02-19  Richard Hughes  <richard@hughsie.com>
 * data/gnome-power-manager.schemas.in, src/gpm-prefs.h, src/gpm-manager.c: Only use lock_on_blank_screen, lock_on_suspend, lock_on_hibernate as this should give us enough power for custom users and also simplicity so we don't have a dozen keys. We default to gnome-screensaver settings.
Comment 6 Richard Hughes 2006-02-19 16:41:18 UTC
Jaap, can you check this all works okay and then close this bug? It seems to work for me.