Arriving late to the discussion, so just my 2 cents: 2010/1/26 Aaron J. Seigo <ase...@kde.org>: > On January 26, 2010, Ivan Čukić wrote: >> On Tuesday, 26. January 2010. 11.57.36 Riccardo Iaconelli wrote: >> > On Monday 25 January 2010 13:20:56 Marco Martin wrote: >> > > opinions? comments? >> > > would like to hear some feedback before implementing anything since >> > > each solution would lead to a different total screwing of the current >> > > implementation :p >> >> What about having something like Facebook does - one small notification >> popup at a time, and when the user clicks the 'show notifications' he/she >> gets the list of notifications. >> >> We don't need to go for the list as well, but since the user clicked the >> 'show notifications' button we don't have the problem of contextual >> information covering a large part of the screen - it is what the user >> wanted. > > the problem is when we have 10 notifications from one app and 1 from another > plus a few running jobs.
There's an easy solution for that: group notifications by application when showing them for the first time. Say you have Kopete throw in 5 notifications, then the important Low Battery shows, then Kopete rapid-fire 20 notifications more. Final result? Two alerts on screen, on of them is Low Battery - the other is a pile of 20 Kopete notes, latest on top. This solves the problem of bad-behaved applications, they will not spam the screen even when they are the only player in town. When you really want to see what it had to say, you can expand that pile of 25 notes (and maybe even regroup them later). Simpler than a priority scheduler, ain't it? Maybe you could even explain to Aunt Tillie how it works! ;-) 2010/1/26 J Janz wrote: > Having notifications queued (by showing just 1 at a time) seems like a good > idea to clean up the desktop but it could bring more trouble than just that > inconvenience. > 2010/1/26 Marco Martin: >> if the mouse is already somewhere over a notification any new notification >> should be queued and not displayed until the mouse leaves > > Yeah but, see, if you have one notification at a time, this totally ruins > the purpose of battery (or whatever else)'s urgency on telling you your > power is going away. If the mouse is over a notification, we can safely assume the user is paying attention to notifications. Having the user attention makes many notifications turn from "clutter" to "information". So the original motivation for limiting the number of shown alerts is not present while the user is reading them - additional alert groups could be shown in that case, but be limited to one (or two, or three) group otherwise. This has the benefit over a "show me everything" persistent state that it only fills the screen when the user is looking for it, avoiding the "kopete noise in the backgroung". It's true that when the mouse is over a notification it should NEVER, EVER change to a different one (that's an important thing, guys!) but the solution is not hiding new information, is placing it somewhere else. In the example, say I get a new mail notification. I hover the mouse over it to read the mail's subject, and the battery notification runs. What's the best thing to do? Not to hide my mail note, not to hide the low battery note. Guess it? Just show the new battery alert below (or above) the user-selected mail alert! _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
