[PATCH] Turn Powerdevil suspend notification into a dialog

[Aaron J. Seigo]

On September 22, 2009, Thomas Lübking wrote:
> Regarding this is /the/ moment to break the users workflow and pull his
> excllusive focus, one could make this a fs window (covering Aarons "user
> confused about dialog source" argument)

or "how to piss off a user because the developer thinks they know better"

modal behavior is evil, interrupting the user is a sin. never, ever get in the 
way of what the user is doing. if you must get in their way, only do so when 
they have explicitly said you may.

so i go back to: what is the actual real world failure we are attempting to 
fix? right now we have fixes for something that isn't, as far as we know, 
actually broken. and the fix introduces a new kind of broken.

> This event is exceptional 

yes. that doesn't justify interrupting the user or creating a modal state.

> and /outside/ the workspace/workflow.

power management is generally perceived as part of the workspace. just like 
shutting down, restarting, etc are.

> Its handling should, can and must not be scheduled and the event cannot be
> ignored.

use case:

i walk away from my computer.
i forget it's not plugged in.
this dialog pops up when i'm not in the room.
result: event is ignored.

the event can and will be ignored. getting in my way while trying to prevent 
that is only going to piss me off (speaking as a user). in fact, it is 
probably MORE likely that i will just click it away to get at my work.

ok, another use case:

the dialog pops up.
i'm in the middle of a conversation.
if it's modal, i can only dismiss it to finish the conversation. so much for 
the computer helping me.

the dialog pops up.
i'm in the middle of a conversation.
it's not modal but it takes focus; i'm more likely to dismiss it quickly 
because it's "in my way". 
once again, the computer is not able to help me.

this is really basic usability: don't get in the way of the user, don't enter 
modal states. it will backfire if we try to run around that.

> Therefore it's different from anything the VisualNotifications are used for

except for other things that may arise that are the same. *shrug* for most 
things in the notifications area, yes, it's different.

> and deserves a drastic treatment.

for the above reasons, i can't agree.
 
> Also the more present the notification is, the less time will the user
>  waste on recognizing the situation and the more time he'll have to plug
>  the AC (in doubt)

or just as likely they'll quickly get rid of the annoyance and forget.
or they will plug it in immediately cursing all the while about how the god-
damned computer keeps getting in their way.

and, because i'm in repetition mode already, where are the bug reports or user 
observation saying "i didn't notice that thing and so i lost data / time / 
something else bad"?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090922/1f005b24/attachment.sig>