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 753713 - Remove "button-*" configuration
Remove "button-*" configuration
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: power
3.17.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2015-08-17 11:00 UTC by Bastien Nocera
Modified: 2016-04-05 23:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
media-keys: Remove "button-*" configuration (4.99 KB, patch)
2015-08-31 16:14 UTC, Bastien Nocera
committed Details | Review

Description Bastien Nocera 2015-08-17 11:00:01 UTC
The button-power, button-suspend, etc. configurations accept a GsdPowerActionType, but not all of the variants are supported:
        case GSD_POWER_ACTION_BLANK:
        case GSD_POWER_ACTION_LOGOUT:
        case GSD_POWER_ACTION_NOTHING:
                /* these actions cannot be handled by media-keys and
                 * are not used in this context */
                break;

Given that we usually prefer to avoid this sort of configuration which should work out of the box, it would be better to have act as they are labelled, and people who want to change the configurations at system level can use udev to apply a new keymap.
Comment 1 Bastien Nocera 2015-08-31 16:14:03 UTC
Created attachment 310374 [details] [review]
media-keys: Remove "button-*" configuration

The button-power, button-suspend, etc. configurations accept a
GsdPowerActionType, but not all of the variants are supported:
        case GSD_POWER_ACTION_BLANK:
        case GSD_POWER_ACTION_LOGOUT:
        case GSD_POWER_ACTION_NOTHING:
                /* these actions cannot be handled by media-keys and
                 * are not used in this context */
                break;

Given that we usually prefer to avoid this sort of configuration which should
work out of the box, it would be better to have act as they are labelled, and
people who want to change the configurations at system level can use udev to
apply a new keymap.
Comment 2 Rui Matos 2015-09-01 12:04:38 UTC
Review of attachment 310374 [details] [review]:

Looks good. Commit message typo: "it would be better to have *something missing here* act as they are labelled"
Comment 3 Bastien Nocera 2015-09-01 13:15:20 UTC
With the typo in the commit message fixed.

Attachment 310374 [details] pushed as 50564cd - media-keys: Remove "button-*" configuration
Comment 4 optional real name 2015-10-10 23:51:41 UTC
this is not really well-thought-out change
1. if buttons should do what they say on a tin why power button does suspend and not poweroff the system?
2. how do i make power button interactive? (as it was possible in 3.16)

is there a way to roll back this change?
Comment 5 Ihor 2015-10-17 09:43:51 UTC
Bastien Nocera,

could you explain how to use udev to apply a new keymap? I want my power button to show dialog instead of immediately suspend.
The best it would be revert this "fix".

Regards,
Ihor
Comment 6 Bastien Nocera 2015-10-19 16:01:41 UTC
(In reply to optional real name from comment #4)
> this is not really well-thought-out change
> 1. if buttons should do what they say on a tin why power button does suspend
> and not poweroff the system?

Fair, but that would just make me change the description of the change, not the change.

> 2. how do i make power button interactive? (as it was possible in 3.16)

You can't. I don't have any plans on making this possible.

> is there a way to roll back this change?

You can run "git revert 50564cd" in a git checkout of gnome-settings-daemon, and apply that patch to your version of gnome-settings-daemon.
Comment 7 Eric 2015-11-04 05:51:06 UTC
Bastien,

As pointed out here: https://www.reddit.com/r/gnome/comments/3oddse/buttonpower_gone_in_318/


The call:
GSettingsComboEnumTweak(_("Power Button Action"), "org.gnome.settings-daemon.plugins.power", "button-power", size_group=sg)

is still being made here:
https://git.gnome.org/browse/gnome-tweak-tool/tree/gtweak/tweaks/tweak_group_shell.py#n111


I also prefer the interactive dialog. As Ihor asked, could you please give an example of a udev rule that will yield the same interactive dialog and/or poweroff when pressing the power button?
Comment 8 Bastien Nocera 2015-11-04 11:15:53 UTC
(In reply to Eric from comment #7)
> Bastien,
> 
> As pointed out here:
> https://www.reddit.com/r/gnome/comments/3oddse/buttonpower_gone_in_318/

I'm not going to increase my blood pressure by reading reddit.

> The call:
> GSettingsComboEnumTweak(_("Power Button Action"),
> "org.gnome.settings-daemon.plugins.power", "button-power", size_group=sg)
> 
> is still being made here:
> https://git.gnome.org/browse/gnome-tweak-tool/tree/gtweak/tweaks/
> tweak_group_shell.py#n111

You'll need to file a bug against gnome-tweak-tool.

> I also prefer the interactive dialog. As Ihor asked, could you please give
> an example of a udev rule that will yield the same interactive dialog and/or
> poweroff when pressing the power button?

See bug 755953.
Comment 9 Bastien Nocera 2015-11-04 14:26:31 UTC
(In reply to Eric from comment #7)
> I also prefer the interactive dialog.

(In reply to optional real name from comment #4)
> 2. how do i make power button interactive? (as it was possible in 3.16)

In https://bugzilla.gnome.org/show_bug.cgi?id=755953 could you please answer those questions:
- Can you explain why you prefer the interactive dialogue? Do you use it to hibernate the machine? Or to suspend it? Or to power it off? If you use it to power off, why not use the power off menu item in the status menu?
- Are you using this on laptops or on desktops?
Comment 10 Momcilo Medic 2015-11-10 17:11:55 UTC
Hi friends!

I can somewhat agree with the logic that buttons should do as labeled.

However, on most notebooks, power button suspends the computer which usually is not the desired behavior.

IMO, we should keep the settings as this option is often customized and opposite doesn't bring any improvements.

Kind regards,
Momcilo Medic.
Comment 11 Bastien Nocera 2015-11-10 17:17:48 UTC
(In reply to Momcilo Medic from comment #10)
<snip>
> IMO, we should keep the settings as this option is often customized and
> opposite doesn't bring any improvements.

Best read the bugs completely before commenting. Already fixed and released.
Comment 12 Momcilo Medic 2015-11-10 21:14:53 UTC
I am sorry for the noise then, I didn't follow up in the other bug.

Keep up the good work.

Kind regards,
Momcilo.