Notifications-future, a recap

[Mark]

On Fri, Sep 21, 2012 at 4:42 PM, Mark <markg85 at gmail.com> wrote:
> 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.

Actually, the current galago spec already is flexible enough to add a
pid. The spec [1] doesn't have a pid field, but it does have a "hints"
in which you are allowed to set custom hints. Just add a pid there,
add it to the KNotification side that's sending the notification and
handle it in the receiving side. That will allow you to do anything
you want.

[1] http://www.galago-project.org/specs/notification/0.9/x408.html#command-notify