- Has lid switch -> power brings up dialogue
- DMI says it's a desktop -> power brings up dialogue
- all others -> suspend

Making it depend on the power plugin being merged.

This is definitely the way to go for desktops and laptops; it's certainly what I'd expect to happen.

I'm not sure about the tablet case. My mobile phone shows a power down dialog when I hold down the power button; I'd expect the same behaviour on a tablet. Also, how would you power down this kind of device when it is required? I'm not a fan of mandating the use of log out to power down - log out only really makes sense on devices with multiple user accounts (see bug 657011).

(In reply to comment #1)
> - all others -> suspend

Is the tablet button a "power" button or just a arbitrary button that's been mapped to KEY_POWER? If you hold it down for >5 seconds, does the tablet do a hard-ACPI poweroff?

Using the physical power button as the primary way of shutting down could be better than the current log out > power down behaviour. This would require that the button behaves consistently though (hence bug 657068).

(In reply to comment #3)
> Is the tablet button a "power" button or just a arbitrary button that's been
> mapped to KEY_POWER? If you hold it down for >5 seconds, does the tablet do a
> hard-ACPI poweroff?

I don't think there's any sort of "PC tablet requirements" spec that would allow you to answer that question in general, but any tablet would have to have some way of powering off when the software had crashed and wasn't responding, right?

In the specific case of the ExoPC/WeTab, yes, it has a real power button.

FWIW, I strongly disagree with this bug. I think suspending by default is the best choice for all devices. I have an old imac "desktop" on my desk at work and it suspends by default and it is great. I have a tablet that suspends by default and it is great. I have a laptop that suspends by default and it is great.

Powering off is not a good default. Showing a dialog (we're trying hard to reduce dialogs) is not a good default. Just "stopping the computer and optimizing for fast and complete resume" is the best default. We call that Suspend.

There are bugs that we should endeavor to fix:

 * Make the long press work dammit
 * Make an "alt" alternative for touch devices
 * Make our restart for upgrades workflow way way better

Just thinking out loud here. One option for the "alt" alt. Is to long press on the Suspend menu item and expand a inline submenu with other options.

maybe a clickable disclosure triangle next to suspend ala the network menus (with the difference that short clicking Suspend wouldn't expand the menu, only clicking the triangle would, or long clicking suspend would) ?

Too small, fiddly, and easy to err.

we probably need some subtle way to notify users when they're long pressing that something's happening, but that applies for the long-press menus in the dash, too, so is orthogonal to this bug I guess.

(In reply to comment #6)
> There are bugs that we should endeavor to fix:
> 
>  * Make the long press work dammit

What we want is suspend on short press and power off dialog on long press, no? My understanding is that we currently only have control over the long press - and that's what's being discussed in this bug.

Allan, on a lot of hardware, if the user taps the power button we don't get a separate button press and release events. just a "power button was tapped" event.  If the user holds for a long time, we don't even get that, it just turns off.

I've filed bug 657175 to track better feedback before and during long clicks

(In reply to comment #12)
> If the user holds for a long time, we don't even get that, it just
> turns off.

To be ACPI compliant, the hardware power button has to do an EC hard poweroff if held for more than 5 seconds. You can't disable that, the functionality is burnt into the EC microcode or the BIOS ROM image.

Richard.

(In reply to comment #6)
>  * Make our restart for upgrades workflow way way better

I'm discussing the details on the systemd mailing list at the moment. All the session-level stuff to make this possible is already in place.

(In reply to comment #12)
> Allan, on a lot of hardware, if the user taps the power button we don't get a
> separate button press and release events. just a "power button was tapped"
> event.  If the user holds for a long time, we don't even get that, it just
> turns off.

Why are things never simple? ;)

Despite that, and despite completely agreeing with the intent described in #c6, I'm still inclined to agree with the proposal in this bug.

The default way to stop using a laptop is to close the lid, and the default way to stop using a desktop machine is to either just walk away or to suspend via the user menu. So, even though it isn't the preferred behaviour, having any use of the power button trigger the shut down dialog is consistent with 'suspend is the default', since the power button is unlikely to be the primary means of interaction.

That still leaves the tablet case, of course.

There is no "default way" for human interactions especially when you don't design the hardware. There are defaults for actions and system behaviors though. I use the hardware button exclusively on my desktop systems, not the menu.

So it isn't true at all that the power button is unlikely to be the primary means of interactions. Honestly, I think this is a really bad idea.

Long press is a no-go now, maybe in the future, but we need something better in the meantime, we get a lot of complains about the current suspend behaviour. We could try to play with multiple presses like for example showing a dialog:

Suspending in $CONTDOWN 

[reboot] [<power button symbol> poweroff]

with a very short countdown, like 5 sec or even less, pressing the power button again would visually press the poweroff button in the dialog shutting down the machine, well or something along the lines.

(In reply to comment #1)
> - Has lid switch -> power brings up dialogue
> - DMI says it's a desktop -> power brings up dialogue
> - all others -> suspend
> 
> Making it depend on the power plugin being merged.

That makes sense to me.

(In reply to comment #2)
> This is definitely the way to go for desktops and laptops; it's certainly what
> I'd expect to happen.

Well only downside here is that the power button is not always convenient to use on desktop systems ("under the desk" etc.). On my desktop system it is on top so it even works when under the desk, but in many cases its not.

As for how to "solve" this ... no idea really.

I filed bug 657496 about handling "soft" power buttons, when we can ask whether to power off when the power button is pressed for long.

I've left the defaults as they were (eg. power will suspend), and the ability to override it through GSettings. Doing anything other than suspending means that our position on using suspend as a default action would be completely muddied.

And bringing it closer to the mockups in https://live.gnome.org/Design/SystemSettings/Power/ I've removed the configuration items for the suspend and power buttons.


commit 6ed654694dae3aae729838ebb986883355b0595c
Author: Bastien Nocera <hadess@hadess.net>
Date:   Sat Aug 27 12:53:54 2011 +0100

    power: Remove power and suspend buttons config
    
    As mentioned in the discussion in:
    https://bugzilla.gnome.org/show_bug.cgi?id=652183
    https://bugzilla.gnome.org/show_bug.cgi?id=657068
    
    And implemented in the future for the power panel:
    https://live.gnome.org/Design/SystemSettings/Power/

*** Bug 657068 has been marked as a duplicate of this bug. ***

I disagree with William and strongly support the original proposal which was to make pressing the power button bring up a dialog to shut down. This would also help relieve some of the heat from bug 643457 and generally make users happy which is a good thing.

There definitely is a valid use case for shutting down or restarting the computer without first logging out. In fact, this is a rather common task & we shouldn't just ignore it or hide that possibility.

Well, certainly this is not RESOLVED, let alone FIXED, so sorry but I'm reopening. We still need sane default for the power button.

(In reply to comment #6)
> FWIW, I strongly disagree with this bug. I think suspending by default is the
> best choice for all devices. I have an old imac "desktop" on my desk at work
> and it suspends by default and it is great. I have a tablet that suspends by
> default and it is great. I have a laptop that suspends by default and it is
> great.
> 
> Powering off is not a good default. Showing a dialog (we're trying hard to
> reduce dialogs) is not a good default. Just "stopping the computer and
> optimizing for fast and complete resume" is the best default. We call that
> Suspend.

Sorry this is just plain wrong. I'm sure you understand that a big group of people (the enterprise users) routinely have to (I underline "has to", no choices here) completely power off, and I'm sure you understand that a big group of people strongly want (and I agree with them) to power off their PCs, for environmental reasons. This means there is a concrete, hard, real, use case for powering off, and ignoring it means going blindly in the wrong direction.

This said, there are currently two ways to power off a computer (ignoring the tens of ways that involve a command line, ignoring shell extensions or custom launchers and ignoring the fallback mode): you can press Alt while the user menu is open, or you can fully log out, then shutdown from GDM. On the other hand, there are four ways to suspend: you can click the suspend item in the user menu, you can close your laptop lid, you can press the sleep button, or you can press the power button.
It is therefore clear that the are too many options for suspending, while there is none for powering off. What this bug is trying to do is to restore an equilibrium, by having three ways for one and three for the other (even though the power off path is still less discoverable).

Finally, as you said, the best default is not suspending, it's "stopping the computer and optimizing for fast and complete resume", which power off (with SSD, systemd for performance, XSMP and EggSM for session restoring) does very well. By tuning for a fast login in the core daemons and keeping persistent state at all times in the apps, we would save power, have a fast resumable system and have also many other advantages (like restartable apps).

(In reply to comment #23)
> Well, certainly this is not RESOLVED, let alone FIXED, so sorry but I'm
> reopening. We still need sane default for the power button.

Is. This bug was about having different defaults in gnome-settings-daemon depending on the hardware type. Which we won't be doing. So there's no reason for that bug to still be opened.

(In reply to comment #24)
> (In reply to comment #23)
> > Well, certainly this is not RESOLVED, let alone FIXED, so sorry but I'm
> > reopening. We still need sane default for the power button.
> 
> Is. This bug was about having different defaults in gnome-settings-daemon
> depending on the hardware type. Which we won't be doing. So there's no reason
> for that bug to still be opened.

Look, I don't want to do a bug dance and reopen it again, but it is fairly clear to me that current defaults are not appropriate, whether you want to differentiate PCs-vs-tablets or not.
It has been said many times, in this and other bugs, by many people, including respected designers, and none of the only two people in support of this resolution (you and William) addressed these concerns (or at least, it was not satisfactory to me).

*** Bug 701995 has been marked as a duplicate of this bug. ***