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

[Thomas Pfeiffer]

> 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.

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


-----------------------------------------------------------
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/20130426/53e665b6/attachment-0001.html>