[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [PATCH] Detecting notification popup server capabilities
From:       Kåre_Särs <kare.sars () iki ! fi>
Date:       2009-09-02 5:37:52
Message-ID: 200909020837.52808.kare.sars () iki ! fi
[Download RAW message or body]

On Tuesday 01 September 2009, Aaron J. Seigo wrote:
> On September 1, 2009, Aurélien Gâteau wrote:
> > Aaron J. Seigo wrote:
> > > On September 1, 2009, Aurélien Gâteau wrote:
> > >> decide to use a dialog box instead (in fact I think this notification
> > >> should always be presented through a dialog box)
> > >
> > > why?
> >
> > Because it's quite critical and requires a very fast response from the
> > user, so I believe this is one of the very few cases where interrupting
> > the user workflow should be allowed.
>
> so a dialog that overrides focus stealing prevention .. in which case it
> risks being accidentally triggered? a dialog that resides on all desktops?
> i don't think this is a very elegant solution.

A dialog box is not an elegant solution, but the cancel action in the current 
notification is a bit hard to hit. I cancel the standby/hibernation quite 
often as I have a laptop that runs on batteries about 20 minutes after the 
battery meters has gone to 0% and 10 seconds is not enough time to go and get 
the power cable.

For me, the most elegant solution would be to have the cancel action in the 
power-management plasmoid (assuming it is running) and not in the notification 
it self.

My point being that the "critical" actions probably should not be in the 
notifications.

-- 
Kåre Särs

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic