Notifications-future, a recap

[Dario Freddi]

(putting back plasma-devel on CC, since the discussion is quite relevant)

2012/9/17 Sune Vuorela <nospam at vuorela.dk>:
>> 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
>
> yep. the plan is
> 1) write a small library wrapping the org.freedesktop.notification api
>    wrap growl on mac

OT: you don't want to wrap growl but probably the new native
notification system.

>    wrap QSystemTrayIcon on windows
> 2) do something similar for audio notifications
> 3) retrofit knotification on top of those
>
> and the more I have investigated, 1) should actually be put into Qt and
> QPA.
> That should also make it possible for e.g. webkit to use it to show web
> notifications.
> Unfortunately, I'm currently a bit busy with stuff :/
>
>> 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
>
> Really? I_think we should get rid of a daemon and just let the workspace
> shell handle it.

It really depends on what you want to achieve. If your goal is just
cleaning up the API and implementing the existing standard it might
work out, but for sure it won't just cut it for what I proposed, where
we need a centralized logic for dispatching, grouping and more. As
Marco also said (framework wasn't CC'ed tho), the applet is already
gearing towards being a dull observer.

> I have a hard time figuring out why the above quite simple steps don't
> solve the problems you're specifying (and even ensures that you keep all
> existing applications working with their notifications)

Well :D. There is no way you can group notification, no way you can
tie them to activities, no way you can dispatch notifications to
different handlers than the workspace, and more. So I guess it's
rather safe to assume that the current design just won't cut it, and
as I already said applications will still be able to work with the
existing API, they just won't be able to expose the full experience -
and in some cases where they just shoot out a transient bubble, they
won't even notice the change.

I guess the real question is whether we want to continue with the old
paradigm we have or try to bet on something more modern. Also, what I
am proposing can still be adapted to interact with other platforms -
as I said, the client API should be as minimal as possible and not
tied to the complexity of the server.

>
>
> /Sune
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel