Review Request 110122: Patch to handle notifications with low timeouts masking earlier important notifications.

Fri May 3 18:38:02 UTC 2013

> On April 25, 2013, 2:02 p.m., Aaron J. Seigo wrote:
> > plasma/generic/applets/notifications/contents/ui/LastNotificationPopup.qml, line 52
> > <http://git.reviewboard.kde.org/r/110122/diff/1/?file=140373#file140373line52>
> >
> >     no minimum is set here as there was in the prior code. there should probably be some sensible minimum applied.
> 
> James Pike wrote:
>     The minimum is set on line 45.
> 
> James Pike wrote:
>     I did however remove the 60 second maximum as I believe this is too low, many people in my office have expressed a desire for higher notification timeouts. I mark notifications from my boss with a timeout of several thousand seconds to ensure I never miss them. Else he'll get angry.
> 
> James Pike wrote:
>     Please feel free to re-instate the 60 second maximum though, it just means I'll never be able to use KDE and have a non-angry boss at the same time :P
> 
> Thomas Pfeiffer wrote:
>     If an information is so important that you must not miss it, it should not be displayed as a notification (or at least not only). Notifications should only be used for information that may be interesting, but not critical.
>     If you have to set timeouts to basically "forever", that's a sign that you're using a notification for the wrong purpose.
> 
> James Pike wrote:
>     And sure, I have audio notifications on top. Yet I still think, it's not up to you to decide purpose, to decide the notification period. To decide on behalf of everyone else. I didn't think that was the KDE philosophy at all, I thought the philosophy was on user configuration. So IMO to decide on a blanket 60 second maximum for everyone and enforce that is wrong.
>     
>     Do you really wanna be the kinda person who tells an entire community about what purpose "should be"?
> 
> James Pike wrote:
>     Essentially I'm asking, why do you feel you have a mandate, as a WM, to override hints given by user applications? Why do you assume a user application cannot have a timeout above 60 seconds? Way too authoritarian for my likings...
> 
> James Pike wrote:
>     The number of applications that would set long notifications maliciously VS the number of people who may want notifications longer than 60 seconds... that's an argument I'd bet large amounts of money on winning.
> 
> Thomas Pfeiffer wrote:
>     I agree that if the API excepts any value for the timeout, values should not be overridden at a later point. If a developer or user is allowed to set a timeout of 1000s, than it should show for 1000s.
>     
>     What this situation clearly shows me, though,  is a mismatch between the mental model of the developers of the notification system and its users. A timeout of 1000s is a workaround for "I don't want my notification to go away". And whenever people work around something which is done by design, there is a gap between designer and user.
>     Therefore it seems to me that we have to rethink what purpose the popup notifications are designed for and make it work well for that purpose without the need for workarounds. And if users need a kinf of notification for which the popup notifications were not made, we need a new kind of notification, not a workaround.
> 
> Thomas Pfeiffer wrote:
>     And I apologize for at first not acknowledging your - justified - argument that a program should not accept a value at first and then override it later. My argument that a timeout of 1000s means that something is wrong dominated my mind at that point.

since the notification timeout comes from the shared dbus api to do notifications we don't have much degrees of freedom api-wise (it has also to support gtk apps, or old apps).
one thing that may indeed happen is the ui that has to work a bit around the api to achieve the design that was in mind for that particular piece.

the small notification that automatically pops up is quite a "dangerous" thing ui wise, it should be as less invasive as possible, that's why we forbidden notifications to stay there for 1000 seconds. And for ones that are valid/important for a long time, that's why the notifications history exists

- Marco

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110122/#review31563
-----------------------------------------------------------

On April 25, 2013, 1:58 p.m., James Pike wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110122/
> -----------------------------------------------------------
> 
> (Updated April 25, 2013, 1:58 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Description
> -------
> 
> Currently the timeout of the last notification to arrive is used as a basis for hiding the notification display. This means that a notification with a high timeout can get hidden by a new notification arriving with a much lower timeout.
> 
> This patch simply changes the behaviour to, when expiring a timer, go back through the stack and display the most recent unexpired timer. If all timers are expired the notification is closed as before.
> 
> 
> This addresses bug 318295.
>     http://bugs.kde.org/show_bug.cgi?id=318295
> 
> 
> Diffs
> -----
> 
>   plasma/generic/applets/notifications/contents/ui/LastNotificationPopup.qml 2fa1b11 
> 
> Diff: http://git.reviewboard.kde.org/r/110122/diff/
> 
> 
> Testing
> -------
> 
> Test script in https://bugs.kde.org/show_bug.cgi?id=318295
> 
> 
> Thanks,
> 
> James Pike
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130503/049b0aa1/attachment-0001.html>