Notifications-future, a recap

[Dario Freddi]

Hello everyone,

you might or might not know by now of my intention of revamping the
way we deal with notifications in KDE as I explained in my last blog
post http://drfav.wordpress.com/2012/09/17/the-notifications-issue-part-3-the-possible-solution/
. I have been talking about this with many of you already but I think
it's time to see what's the overall reception to the idea and what's
coming up for the actual job.

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

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?