Notifications-future, a recap

[Dario Freddi]

2012/9/21 Mark <markg85 at gmail.com>:
> On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi <drf54321 at gmail.com> wrote:
>> (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.
>>
> <snip>
>
> I'm not quite sure if i agree with you there. The following is all
> based on assumptions!

You missed the point - the discussion was not on the API as I said,
and I'll repeat for the 1 billionth time that the current API will
still work for the majority of cases. The discussion was on the
structure of the internal system, which at the moment doesn't allow
any of the features listed above to be exposed, via any possible kind
of API.

When I referred to "they just won't be able to expose the full
experience" I was referring to that small percentage of applications
which, for example, belong to an activity but need to stream an event
which belongs to a different one, such as the contact list example I
put in my blogpost. But the API is there for staying.