[PATCH] Turn Powerdevil suspend notification into a dialog

[Sebastian Kügler]

On Tuesday 22 September 2009 18:38:07 David Nolden wrote:
> Am Dienstag 22 September 2009 16:09:51 schrieb Sebastian Kügler:
> > On Tuesday 22 September 2009 14:19:57 Aurélien Gâteau wrote:
> > > What do you think about this?
> >
> > 
> > NAK. The notification comes from the system, the workspace (which is
> > where powerdevil lives) not from an application, it's also where other
> > notifications of system hardware state come from (network connected,
> > power connected, ...) that's where it should stay. Having it in a
> > notification, and thus always in the same location actually makes it a
> > lot easier to find the dialog, especially when you're in a hurry. Making
> > it a dialog would be a step back IMO as it looks less integrated and
> > those small dialog windows tend to get lost behind other windows. From my
> > point of view, a dialog is a no-go here. Besides, this is the exact use
> > case why we do have actions on notifications. We should not move it do
> > dialogs at any price only to not need actions on notifications (like the
> > Ayatana spec requires). I've shared my view on this particular piece of
> > the Ayatana spec more than once already, and I'd rather not repeat it
> > over and over. 
> >
> > > The second patch increases the default timeout from 10 seconds to 30
> > > seconds, giving the user more time to react.
> >
> > 
> > OK from my POV, but probably 20 seconds is also enough. I've never missed
> >  to cancel a suspend even with it being 10 seconds. (Maybe this part of
> > the patch is a sign that it now takes you longer to locate the cancel
> > action?) 
> 
> The notification area was designed to get notifications _out of the way_
>  to  not disturb the users workflow. And that's why this notification does
>  not belong there. Suspending the machine breaks the users workflow anyway,
>  and might even completely destroy it, there is no reason for this action
>  to stay out of the users sight.

You don't want to disturb the user, because you tell him "save your stuff NOW". The 
last thing you want in that situation is a dialog smacked onto the center of the 
screen.

Instead, we need to focus on making notifications pop up when the machine needs 
attention (or someone else). This is made clear by visual design, including the 
location. If we put heaps of useless notifications everywhere, then sure, we'll need 
another way for the display of high priority notifications. Priority is something 
that's actually covered in the Notification Spec. Which notification need showing is 
a config thing.

> Furthermore, the notification area tends to be spammed with tens of 
> notifications (a la requesting http://) so the important notification may 
> easily get lost between such 'spam'.

That needs to be fixed, regardless. Introducing another way of notifying the user of 
important system events is not a solution but creates inconsistency and makes this 
problem even worse.

I'm not saying that this piece of user interaction (critical suspend) can't be 
improved. Replacing it with a dialog is just the wrong direction.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090923/d926247c/attachment.sig>