notifications, again :D

[Aaron J. Seigo]

On January 25, 2010, Marco Martin wrote:
> On Monday 25 January 2010, Aaron J. Seigo wrote:
> > On January 25, 2010, Marco Martin wrote:
> > > -only one notification is shown at a time
> > > -still valid notifications scrolls automatically or after arrows press,
> > > like rssnow
> > > bottom arrow would switch from valid to recent expired notifications
> > 
> > i like the idea of one notification at a time as well as being able to
> > scroll through them.
> > 
> > there are some other design parameters here, too:
> > 
> > * what is shown automatically (popped up) as opposed to when the user
> > clicks on the icon
> 
> wonder if it's better to just expand the same popup dialog or creating a
> totally different one...
> i was thinking about just giving a different default height from the
> scroller, like tall just enough to show one vs enogh to show 2 or 3

at least personally, i don't want to see the same content in those two views.

when a notification first happens, i want to just see it.

but when i want to see a specific notification, i would like to be able to 
quickly see what a specific application has said.

the use case is when kopete is busy spamming me and then something i actually 
DO care about appears. when i pop open the notifications area, i want to be 
able to prevent kopete from getting in my way of other notifications.

ah, which brings us to another interesting one: what happens when a critical 
notification like power status comes in? i think that critical notifications 
should pre-empt all other notifications in the auto-popup until they are dealt 
with.

so if a power management notification happens, kopete notifications are 
silently queued up _behind_ that notification until it the critical 
notification is dealt with. (a second stream of notifications, one for 
critical ones and one for everything else is a possibility, but i'm not sure 
it's needed?)

> that makes me pose a question...
> will we still use extenderitems for notifications?

i don't think it's a requirement, really; the entire notification area could 
be an extender, or the notifications versus the jobs, perhaps. or perhaps each 
scroller could be an extender (meaning that each app would get an extender for 
its notifications, and the jobs would get one to share). but if they weren't 
extenders, nobody would die :)


> > as for positioning ... maybe now that we can turn everything else on/off
> > in the system tray it's time to add a feature so that it is also able to
> > be disabled in a given tray.
> 
> well, actually is already posible to enable/disable notifications and jobs
> per-systray
> 
> > in fact, maybe it's time it became it's own plasmoid altogether which is
> > by default hosted in the system tray.
> 
> yes, probably.
> i fear the extraction could be quite painful however :D

now that Applets can advertise their status and the logic is wrapped in a 
DataEngine, it really shouldn't be too difficult to manage. it would mean that 
some special casing for the information widget would be removed in the system 
tray, but that can only be a good thing and force us to find better ways of 
handling that if needed. everything is pretty well encapsulated / separated in 
the system tray, so extraction into a PopupApplet shouldn't be too hard.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks