I thought log out and power off from gdm was the recommended way to shut down?

Feeling sarcastic? ;-)

(In reply to comment #1)
> I thought log out and power off from gdm was the recommended way to shut down?

I think we should use the physical power button as the primary way of powering off. This requires bug 652183 and bug 657068 to be fixed. The log out menu item can be hidden once that has happened.

---

Hmm, the design whiteboard for system Suspend, Stop and Restart [1] states that 'Logout needs to appear on systems with only one user account until we can make language/a11y changes dynamically'.

[1] https://live.gnome.org/GnomeShell/Design/Whiteboards/SystemStopRestart

The more they change, the more they stay the same. We won't be making changes to the behaviour of the sleep/power buttons.

I just want to counter the notion that 'log out' serves no purpose on single user systems. sometimes packages get updated that requires a log out/log in to take effect, and doing that instead of rebooting is much less abruptive. 'Switch user' is another matter.

We also need to fix things like changing language so they don't require logout. I don't think package updates should ever require a logout though. If something is changing in the core OS we should do that outside the user's session.

Created attachment 199662 [details] [review]
user-menu: Hide "Switch user" on single user machines

Ignoring remote logins, the "Switch user" action is meaningless for
single user setups. Do not show it in that case.

(In reply to comment #6)
> We also need to fix things like changing language so they don't require logout.
> I don't think package updates should ever require a logout though. If something
> is changing in the core OS we should do that outside the user's session.

I'll note that MacOS X and Windows cannot do that, and require a restart (MacOS X has the same limitations as Linux/GNOME). iOS does this by restarting all the apps (save state, kill, state will be restored by the app upon restarting in the new language).

Review of attachment 199662 [details] [review]:

Assuming that "has_multiple_users" does the right thing before first notify, LGTM.

::: js/ui/userMenu.js
@@ +533,3 @@
         let allowSwitch = !this._lockdownSettings.get_boolean(DISABLE_USER_SWITCH_KEY);
+        if (allowSwitch &&
+            this._userManager.can_switch () &&

No space between function name and parens.

Comment on attachment 199662 [details] [review]
user-menu: Hide "Switch user" on single user machines

Attachment 199662 [details] pushed as dc5d2b8 - user-menu: Hide "Switch user" on single user machines

Not sure what to do about "Log Out", so leaving the bug open for now.

If userManager gets its information from the accountsservice, this is likely to go wrong when centrally managed user accounts are involved.

<stefw> i guess the big question is if we want to be able to support manually configured kerberos logins.
<stefw> because hiding the log off option, if kerberos, ldap, nis, or other types of logins are in use.
<stefw> is pretty hard to work around
<stefw> there's probably also other flags here, for example multiple desktop environments in use
<stefw> there isn't a single place that would control whether hiding the logoff makes sense or not
<stefw> either it needs to be configured in a common location (eg a file or similar) or owned by a single component (like accounts service)

If kerberos, ldap, nis, etc are in play it isn't a single user system really.

And probably if you have multiple xsession files but only one user then we don't want to show "switch user" but "switch session" or something.

I filed a patch to hide "Log out" as part of bug 675802 - I guess that means we can close this one then?

(In reply to comment #14)
> I filed a patch to hide "Log out" as part of bug 675802 - I guess that means we
> can close this one then?

I think we need to check how this intersects with other parts of the UX. Specifically:

 * software updates (some require you to log out and in again - bug 674964)
 * giving users administrative privileges
 * changing the display language (bug 674429)

In each case, we need to ensure that either (a) logout isn't required or (b) logout or session restart is offered as an option.

Don't mind where that is tracked from - just that it is tracked.

(In reply to comment #15)
> I think we need to check how this intersects with other parts of the UX.
>
> [...]
> 
> Don't mind where that is tracked from - just that it is tracked.

Let's track it here then - "update according to mockups" doesn't really suggests anything like the open issues you point out.

An other reason to logout/login on single user system: Add yourself to a new group

On a single user system Restart works just fine for that.

(In reply to comment #18)
> On a single user system Restart works just fine for that.

you must be kidding, right?

(In reply to comment #19)
> (In reply to comment #18)
> > On a single user system Restart works just fine for that.
> 
> you must be kidding, right?

On systems with graphical environments, the only reason for which you would need to add yourself to a new group is if you were using Debian's antiquated permissions management. We shouldn't be basing design decisions on people wanting to keep the 1970's style permissions when better things exist.

(In reply to comment #20)
> On systems with graphical environments, the only reason for which you would
> need to add yourself to a new group is if you were using Debian's antiquated
> permissions management. We shouldn't be basing design decisions on people
> wanting to keep the 1970's style permissions when better things exist.

The issue is not with debian, but with numerous packages maintained outside the Gnome umbrella that require, and for the foreseeable future *will* continue to require, a user to be in a particular unix group. Just to give an example, I've had to add the user account from which I am posting this message to the vboxusers group to use virtualbox, to android to use the android sdk manager, to cdemu for the cdemu daemon, and to dropbox for the dropbox nautilus extension. I would need to be in a specific group to use samba's "net usershare" functionality. I would need to be in a specific group to allow an application I am working on to connect to systemwide postgresql's socket. Etc.

Would logout be shown when you press Alt ? If so, I can live with that. If not, I seriously think this "design" is flawed; as already pointed out there are various reasons where one does need to logout even on a single user system that are not related to GNOME per se. Without logout you actually degrade installation of 3rd party software like dropbox and virtualbox by adding "and now reboot after installing". While I know that GNOME is not in control of 3rd party software, it might make sense to actually think about all the impact of these proposed changes.

In any case, if this goes through completely hidden there is of course also a simple workaround: create a new user with invalid password "icanlogoutnow".

IMO a user indicates his need for a logout button when there are more than one desktop environments installed. So if there is more than one destop file in 

/usr/share/xsessions/,

there should be clearly a logout menu entry even if there is only one user

(maybe this is the case already, i did not test it).

(In reply to comment #23)
> (maybe this is the case already, i did not test it).

Yes, that's the case.

Closing this because "in certain circumstances" is not really actionable; we already show Log Out if there are multiple user accounts or multiple desktop sessions installed. For the case of remote user accounts, a separate updated bug report would be welcome.

We don't expose UNIX groups and never will; if you can figure out how to edit groups with a terminal, you can figure out how to use loginctl to log out.