Notifications-future, a recap

[Dario Freddi]

2012/9/17 Marco Martin <notmart at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel