2012/9/17 Marco Martin <notm...@gmail.com>: > On Monday 17 September 2012, Dario Freddi wrote: >> I know Sune already had some plans for the notification stack and I >> think that's one of the best times for discussing what's going to >> happen. I seriously doubt we can rely on the old KNotification code, >> and probably we'll have to change some things during the way, but I am >> rather confident we can keep a sort of source compatibility with the >> old API (although I think it's not desirable since the way >> applications interact with notifications is a major point in this >> potential change). > > this will probably need a balance between needed capabilities and entry > barrier for applications to use it, sending a notification could probably not > change much (besides extra data such as what activity it belongs), but > something new would be needed for managing the notification lifecycle after is > sent...
exactly that >> My personal idea is to have a new (tier1) framework consisting of a >> way for building handlers, a client API and a server API (so that the >> server can be put into runtime rather easily). Marco is already doing >> some work on the applet to make it "ready" to adapt to this new >> concept. Ideally, the applet will just receive a model of the existing >> backlog + additional messages for transient notifications and newly >> spawned persistent ones. >> >> What do you think? > > to repeat to everybody what i said to dario, the notifications applet i'm > rewriting, it should be almost ready to be a quite dumb visualization of > whatever is the backend. when/if the models of the notifications are ready, so > data + exposed actions (delete, execute action "foo", mark as read...) are > there, even tough not immediate should be quite easy to add this source in the > notifications applet. > > to comment purely on the idea, i would like a lot a more capable notifications > system, with stuff like > * notifications tied to activities > * reliable way to decide when to display the osd popup and when just in the > history > * when not to archive in the history > * when an action can be executed more than once and when doesn't > * what should be shown in the history almost forever, what should go after a > while > > probably some of those things can be achieved by extending the current system, > some don't, maybe there will be compromises to be done.. that was more or less > my wish list to santa tough it's pretty much on the board :) just that 90% of this will happen in the background (server), whereas handlers will just take care of showing a model and a set of events. The aim is to make the client API as simple as possible and have a fatter server. > > Cheers, > Marco Martin > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel