On Fri, Sep 21, 2012 at 4:42 PM, Mark <mark...@gmail.com> wrote: > On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi <drf54...@gmail.com> wrote: >> (putting back plasma-devel on CC, since the discussion is quite relevant) >> >> 2012/9/17 Sune Vuorela <nos...@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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
