[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:       Aurélien Gâteau <aurelien.gateau () canonical ! com>
Date:       2009-09-02 13:19:47
Message-ID: 4A9E70F3.5040204 () canonical ! com
[Download RAW message or body]

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.

I agree it's not a very elegant solution, but I believe it's better than 
the current one and can't think of a better idea.

Anyway, this is getting a bit off-topic.  Let's forget this patch as it 
won't be applied and extending a library API without upstream consent is 
a big no-no in my book.

Instead I am going to patch knotify4 to silently discard actions when 
running in an action-less notification environment.  As Olivier said, 
developers should not assume that actions are always displayed, since 
most knotify notification plugins do not support them.

Do you think this patch could be upstreamed?

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