Notifications-future, a recap

Marco Martin notmart at gmail.com
Mon Sep 17 17:53:21 UTC 2012


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...

> 
> 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

Cheers,
Marco Martin


More information about the Plasma-devel mailing list