[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