Notifications-future, a recap

[Mark]

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!

"There is no way you can group notification"
When a notification is send it also sends the appname
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/knotification_8cpp_source.html
line 370 so you can just group based on appname, right?

"no way you can tie them to activities"
That might be so, but "if" the PID id of the app that had send the
notification is known then you certainly should be able to point that
back to an activity. This does assume that each activity knows which
pid is living in there. There must be some mechanism here already
since the taskmanager is also able to display only the tasks from the
current activity.

...

I'm not saying your're wrong or right, just that it might not be as
black/white as you write it down. Also, i have no experience at all of
the notification system so i might be completely wrong here. It's just
that i don't really think that the above mentioned points are "not
possible". They probably are with some more work.

Also, Sune's idea of making a QPA out of it sounds really nice :)
I think that if you know the pid that send the notification you can do
about anything you want.