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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
