Notification bloat (4.xx)

[Thomas Pfeiffer]

On 24.05.2014 02:54, Celeste Lyn Paul wrote:
> There definitely needs to be better logic when it comes to showing
> certain types of notifications. One of KDE's strengths is that all
> notifications are channeled through the same system, and so KDE can
> control the behavior of all notification interruptions.
>
> I'm not sure at what level this "behavioral logic" needs to live -- I
> assume knotify but I'm not 100% sure what all lives there versus plasma.
>
> For example: You are downloading many files. Some take a short amount of
> time, some take a long time. Regardless, it is not uncommon that you get
> several notifications -- one after another -- to say: your file is down.
> It would be trivial to the user to delay some of these notifications a
> few seconds to minimize interruption. E.g., maybe don't show a
> notification of the same type of message from the same application
> within x seconds. Notifications that are not important can be hidden in
> the history. Notifications that are important can have a delayed display
> until x seconds has passed or the user isn't doing something important
> (like typing).
>
> As I said, just one example. I'm sure we could come up with a dozen use
> cases like this. I guess the question is if it would be worth it enough
> to the user to invest in smart logic like this in the next version of
> knotify.
>
> Many times applications currently control this some of this level of
> behavior, but maybe it is something that should be enforced at the KDE
> UX level?
>
> Just a thought.
>
> ~ Celeste

I think this should be handled at the central level, i.e. in Plasma, 
because we want this to be consistent in general, and that's usually 
easier to reach by controlling it centrally then by writing guidelines.

How do you suggest we approach this?