[RFC] [Logout screen] Shorten timeout to 10 seconds
AbandonedPublic

Authored by ngraham on Jan 31 2020, 10:24 PM.

Details

Reviewers
None
Group Reviewers
VDG
Plasma
Summary

A lot of people seem to think the 30-second timeout is way too long; See Bug 253405 and
the comments and duplicates.

This patch switches to a 10-second timeout.

Open for comments since I don't feel particularly strongly about this one way or another
or really understand why a 30-second timeout was chosen in the first place.

BUG: 253405
FIXED-IN: 5.19.0

Diff Detail

Repository
R120 Plasma Workspace
Branch
shorter-timeout (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 21934
Build 21952: arc lint + arc unit
ngraham created this revision.Jan 31 2020, 10:24 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJan 31 2020, 10:24 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
ngraham requested review of this revision.Jan 31 2020, 10:24 PM

It's meant as a confirmation screen as it's a destructive action, which a user would confirm.

No one is meant to be sitting around waiting for the timeout so
I don't see a compelling reason to make it shorter. None of the bug reports have a good reason why they would do that.

Resolved-wontfix

cfeck added a subscriber: cfeck.Feb 1 2020, 12:06 PM

Why is there a timeout at all?

The (broken) rationale is you can just bash the power button and walk away. Useful if you have a large lab of machines or something.

In practice apps can then block logout afterwards.

(And probably it's there because windows at the time worked like this..)

cfeck added a comment.Feb 1 2020, 12:38 PM

But the timeout isn't used to give apps more time needed to clean up before they confirm the session can be closed? If I understand it correctly, there should be two timeouts?

But the timeout isn't used to give apps more time needed to clean up before they confirm the session can be closed? If I understand it correctly, there should be two timeouts?

I don't think so. It doesn't look like apps get the signal to quit until after you actually choose an option in the dialog, or the timeout runs out.

Conceptually speaking, having any kind of timeout on a dialog meant to confirm destructive actions is a bad idea. You want the default to be to do nothing, not "do the destructive thing in n seconds". So maybe this isn't actually a destructive action at all. After all, an app with unsaved changes or active processed will block the logout/shutdown absent user interaction.

Windows no longer even uses a "confirm logout" dialog anymore AFAIK. However macOS does, with a 60-second timeout.

If I think about it a bit more, what makes sense to me is to never show the logout screen in response to a user-initiated action to choose a specific action (e.g. choose log out, shut down, etc from Kickoff). In this case, the user already knows what they want to happen and asking them to confirm is just annoying. However, when pressing the power button, the multi-option screen should be shown by default, with no timeout at all so you need to deliberately choose an option.

Does that make sense to anyone else?

broulik added a subscriber: broulik.Feb 1 2020, 4:41 PM

Having Kickoff confirm shutdown could be superfluous as you already had to go through the trouble of opening it, going to "Leave", but for e.g. the lock logout entry or generic " Leave" in the desktop context menu I'd still want a confirmation.

Having Kickoff confirm shutdown could be superfluous as you already had to go through the trouble of opening it, going to "Leave", but for e.g. the lock logout entry or generic " Leave" in the desktop context menu I'd still want a confirmation.

Also the lock/logout applet if someone has added it to a panel. One accidental click can invoke the leave/timeout screen.

Having Kickoff confirm shutdown could be superfluous as you already had to go through the trouble of opening it, going to "Leave", but for e.g. the lock logout entry or generic " Leave" in the desktop context menu I'd still want a confirmation.

Yes, I agree.

Essentially, whenever you choose a specific action, confirmation is annoying, but whenever you don't (pushing the power button, clicking the generic "leave" item, etc) it's critically important.

If we did this, we could probably remove the "Confirm logout" and "Offer shutdown options" checkboxed in the Desktop Session KCM since the logout screen would always be shown only when actually needed

But the timeout isn't used to give apps more time needed to clean up before they confirm the session can be closed? If I understand it correctly, there should be two timeouts?

That's different

Order is

action invoked
This confirmation / timeout
ask all apps if they're ok with quitting
ask all apps to quit
if they don't reply then there's a different timeout
then we kill them

So maybe this isn't actually a destructive action at all. After all, an app with unsaved changes or active processed will block the logout/shutdown absent user interaction.

That only happens if you happen to have unsaved changes. Many applications will simply abort any active ongoing process when asked to shutdown. The entire thing is a destructive action because of the major workflow interruption it causes, not necessarily only because of the risk of losing data.

Windows no longer even uses a "confirm logout" dialog anymore AFAIK. However macOS does, with a 60-second timeout.

And opinions are quite mixed on whether that was a good idea or not. See https://social.technet.microsoft.com/Forums/lync/en-US/9cf7e889-20bd-442e-bd4a-4d23a6e10ba6/windows-7-confirmation-when-clicking-shutdown for example.

If I think about it a bit more, what makes sense to me is to never show the logout screen in response to a user-initiated action to choose a specific action (e.g. choose log out, shut down, etc from Kickoff). In this case, the user already knows what they want to happen and asking them to confirm is just annoying. However, when pressing the power button, the multi-option screen should be shown by default, with no timeout at all so you need to deliberately choose an option.

This is making a big assumption: That you never end up accidentally clicking one of the shutdown options. I do not think that is true at all, I know I have done this. In addition, with the proposed changes in https://phabricator.kde.org/T12192 I can see that happening much more often.

For people that are really bothered by it, we already have the option to not ask for confirmation. I do not think we should remove the confirmation, though I do not have a strong opinion on whether there should be a timeout or how long that timeout should be.

ngraham abandoned this revision.Feb 3 2020, 10:06 PM

All right, sounds like this isn't a clear winner.