Re: Notifications-future, a recap
2012/9/21 Mark : > On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi wrote: >> (putting back plasma-devel on CC, since the discussion is quite relevant) >> >> 2012/9/17 Sune Vuorela : 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'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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Notifications-future, a recap
On Fri, Sep 21, 2012 at 4:42 PM, Mark wrote: > On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi wrote: >> (putting back plasma-devel on CC, since the discussion is quite relevant) >> >> 2012/9/17 Sune Vuorela : 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'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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Notifications-future, a recap
On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi wrote: > (putting back plasma-devel on CC, since the discussion is quite relevant) > > 2012/9/17 Sune Vuorela : >>> 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'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. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Notifications-future, a recap
2012/9/21 Aaron J. Seigo : > if the "new" can be achieved by extending or building on galago, that would > seem to me to be a much better thing. > > and no, galago is not perfect. it's not even "great", but it is passable and > widely used and that gives it a lot of value. > > if it turns out that we can not indeed achieve truly useful things without > creating something completely new, we'll still need to support galago > notifications in Plasma Workspaces, and we'll still want a bridge to galago so > we don't lose integration with other workspaces (otherwise our app devs and > users will, rightfully, complain) Exactly - and just to complete the story, I have been there before with inhibition - although KDE now uses its own standard, it still remains 100% back and forth compatible with fd.o's one. So I don't know where it came up that I planned to drop the existing standard, but (especially knowing where I come from) I never thought about it for a second. Aaron got it perfectly right, so I guess we can cut this particular part of the discussion here since we're debating over nothing, and everyone is saying the same thing. > so ... what are the things that can not be achieved by building on top of > galago? > >> GNOME3 notifications are quite good, implementing at least one concept long >> pursued by Notmart's vision (being able to specify which notifications >> should be kept and which notifications are irrelevant). To do this they had >> least expand galago spec. > > key word: expand. this ^. And (at least try to) upstream. > > -- > Aaron Seigo > > ___ > Plasma-devel mailing list > plasma-de...@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
