Re: Notifications-future, a recap
On Friday, September 21, 2012 01:40:51 Alex Fiestas wrote: On Thursday 20 September 2012 19:42:32 Sune Vuorela wrote: On 2012-09-17, Dario Freddi drf54...@gmail.com wrote: 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 Why won't the existing (as in the fdo/galago spec) api cut it to ensure we also play well with others (in both directions) ? Really. All I read is complexity for teh sake of complexity, trying to build walled gardens for the sake of building walled gardens and complicating deployment for the sake of complicating deployment. And I don't think that's neither modern, slick nor futureproof. I don't see how this is incompatible with Dario's vision tbh, we just have to: -Be sure we don't add overhead when deployming in windows/mac/others -Be sure that we are retrocompatible -Be sure that Qt's notification system integrates well (QPA) As about the complexity, it all depends if we want to stay with galago (which imho is an insufficient standard) or we want to try to do something new. new is not a good enough reason to create new incompatabilities. currently KDE notifications work seamlessly in other workspaces, and Gtk+ (and other) apps work seamlessly in Plasma workspaces .. this is due to supporting galago. 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) 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. -- Aaron Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
2012/9/21 Aaron J. Seigo ase...@kde.org: 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-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
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
Re: Notifications-future, a recap
2012/9/21 Mark mark...@gmail.com: 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! 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
On 2012-09-17, Dario Freddi drf54...@gmail.com wrote: 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 Why won't the existing (as in the fdo/galago spec) api cut it to ensure we also play well with others (in both directions) ? Really. All I read is complexity for teh sake of complexity, trying to build walled gardens for the sake of building walled gardens and complicating deployment for the sake of complicating deployment. And I don't think that's neither modern, slick nor futureproof. /Sune ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
2012/9/20 Sune Vuorela nos...@vuorela.dk: On 2012-09-17, Dario Freddi drf54...@gmail.com wrote: 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 Why won't the existing (as in the fdo/galago spec) api cut it to ensure we also play well with others (in both directions) ? Wait. Noone ever said we wouldn't be compatible with the existing spec back and forth, quite the opposite. I just said I'd try to push our changes upstream, this doesn't mean we wouldn't be compatible with fdo, it would be a suicide. The current API simply WON'T ALLOW applications with specific requirements to take advantage of a more fine-grained system. More below. Really. All I read is complexity for teh sake of complexity, trying to build walled gardens for the sake of building walled gardens and complicating deployment for the sake of complicating deployment. And I don't think that's neither modern, slick nor futureproof. I am sorry, but no. If you read my second post it is blatant clear we're lagging behind every possible modern concept of notifications. Example: has Akonadi or any other data-intensive application ever failed on you? It does to me quite often, and I get 30 error spam bubbles my system simply can't handle and drive me mad every time. And what about losing track of incoming mails/messages? Thank god Kubuntu kind of implements support for persistent notifications, otherwise I'd lose every single time people ping me on IRC. If we want to pretend what we have is already enough, we can live in our own small world. But looking outside of our bubble should tell us something, and making us realize we have to try to walk a step forward. Complexity in the server code leads to simplicity to the user and to developers - most of the features I have disclosed won't be exposed through the API - as I explained, most of the grouping can be done with the current means we have. On the client (applet) side, everything would be much easier since the applet would just receive a model. It really can't get simpler than that. A more complex API will be provided to those application which have specific needs, such as contact list. Your average (80%) application will just benefit from SC and won't even notice. You don't want to make your application a handler? Fine, still works. You don't need to associate a specific event to an activity? Fine, still works, and moreover the API will figure this out for you. I really cannot see how this would get more complex to users and developers. Of course it is more complicated than what we have now INTERNALLY, but again you should look at the benefits. If the majority doesn't want this, I won't be the one pushing it, but stating that such a change isn't a step towards being more modern is willingfully ignoring everything outside KDE - I didn't write 3 blog posts for anything, and my first two ones were exactly aimed at answering concerns like yours. Seriously, the only new thing in that concept, in complete honesty, is the activity integration - everything else can be found in any modern interface, be it phone, desktop or web. /Sune ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Notifications-future, a recap
On Thursday 20 September 2012 19:42:32 Sune Vuorela wrote: On 2012-09-17, Dario Freddi drf54...@gmail.com wrote: 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 Why won't the existing (as in the fdo/galago spec) api cut it to ensure we also play well with others (in both directions) ? Really. All I read is complexity for teh sake of complexity, trying to build walled gardens for the sake of building walled gardens and complicating deployment for the sake of complicating deployment. And I don't think that's neither modern, slick nor futureproof. I don't see how this is incompatible with Dario's vision tbh, we just have to: -Be sure we don't add overhead when deployming in windows/mac/others -Be sure that we are retrocompatible -Be sure that Qt's notification system integrates well (QPA) As about the complexity, it all depends if we want to stay with galago (which imho is an insufficient standard) or we want to try to do something new. 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 to at least expand galago spec. Also, empathy and Ktp working in a way of replying to a messaje in the same notification denotes that there are people willing to do more with notifications. just my 2 cents. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
On Monday, September 17, 2012 20:40:33 Dario Freddi wrote: it's pretty much on the board :) just that 90% of this will happen in the background (server), whereas handlers will just take care of showing a model and a set of events. The aim is to make the client API as simple as possible and have a fatter server. is the goal of getting rid of the notifications server as discussed at the Frameworks meetings in Randa off the table then? -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
(readded frameworks, the topic ping-pongs) 2012/9/18 Aaron J. Seigo ase...@kde.org: On Monday, September 17, 2012 20:40:33 Dario Freddi wrote: it's pretty much on the board :) just that 90% of this will happen in the background (server), whereas handlers will just take care of showing a model and a set of events. The aim is to make the client API as simple as possible and have a fatter server. is the goal of getting rid of the notifications server as discussed at the Frameworks meetings in Randa off the table then? Personally, I don't care about who is gonna be the server - and this is also why I started the discussion. The ideas are: 1. A separate daemon, close to what we have now 2. An existing component behaving as a server. Consider that when I am talking about a server it actually means a component implementing a DBus interface. I admit that my POV has changed after 1 year and a lot of research, since I strongly believe the client/visualization and server/dispatcher must be de-paired, otherwise we wouldn't be able to make applications act as handlers. But at the end of the day, we just need something implementing a DBus interface. So I don't know - I kind of like the idea of having a separate component, but even if it was a NotificationServer::init() inside plasma-* it would still be more than enough. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
On Monday 17 September 2012 17:49:23 Dario Freddi wrote: a server API (so that the server can be put into runtime rather easily) Just a note on that: the plan with KDE Frameworks, is that there will be no more libs/runtime separation. A framework will come with any runtime stuff it might need, to make things more modular. Of course if you mean 'there could be multiple servers which handle visualization' then that's different, we don't want a framework to ship all GUIs and therefore end up with too many dependencies. E.g. the kjob framework doesn't ship the plasma visualization stuff :-) But mandatory runtime requirements such as daemons and stuff, should be part of the framework, in the future. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
On Monday 17 September 2012, Dario Freddi wrote: 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 happen. I seriously doubt we can rely on the old KNotification code, and probably we'll have to change some things during the way, but I am rather confident we can keep a sort of source compatibility with the old API (although I think it's not desirable since the way applications interact with notifications is a major point in this potential change). this will probably need a balance between needed capabilities and entry barrier for applications to use it, sending a notification could probably not change much (besides extra data such as what activity it belongs), but something new would be needed for managing the notification lifecycle after is sent... 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 server can be put into runtime rather easily). Marco is already doing some work on the applet to make it ready to adapt to this new concept. Ideally, the applet will just receive a model of the existing backlog + additional messages for transient notifications and newly spawned persistent ones. What do you think? to repeat to everybody what i said to dario, the notifications applet i'm rewriting, it should be almost ready to be a quite dumb visualization of whatever is the backend. when/if the models of the notifications are ready, so data + exposed actions (delete, execute action foo, mark as read...) are there, even tough not immediate should be quite easy to add this source in the notifications applet. to comment purely on the idea, i would like a lot a more capable notifications system, with stuff like * notifications tied to activities * reliable way to decide when to display the osd popup and when just in the history * when not to archive in the history * when an action can be executed more than once and when doesn't * what should be shown in the history almost forever, what should go after a while probably some of those things can be achieved by extending the current system, some don't, maybe there will be compromises to be done.. that was more or less my wish list to santa tough Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
2012/9/17 David Faure fa...@kde.org: On Monday 17 September 2012 17:49:23 Dario Freddi wrote: a server API (so that the server can be put into runtime rather easily) Just a note on that: the plan with KDE Frameworks, is that there will be no more libs/runtime separation. A framework will come with any runtime stuff it might need, to make things more modular. Of course if you mean 'there could be multiple servers which handle visualization' then that's different, we don't want a framework to ship all GUIs and therefore end up with too many dependencies. E.g. the kjob framework doesn't ship the plasma visualization stuff :-) But mandatory runtime requirements such as daemons and stuff, should be part of the framework, in the future. Definitely, sorry for the confusion - the server (handling the grouping/dispatching logic) WILL be shipped with the framework, whereas an API for building handlers (applications, applet) will be provided. TBH I don't see many benefits in allowing multiple servers at this stage - maybe in a bright future, where this could become a standard, it would make sense to have just a way for creating a server. For now I'd stick to the plan of shipping the entire solution :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
2012/9/17 Marco Martin notm...@gmail.com: On Monday 17 September 2012, Dario Freddi wrote: 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 happen. I seriously doubt we can rely on the old KNotification code, and probably we'll have to change some things during the way, but I am rather confident we can keep a sort of source compatibility with the old API (although I think it's not desirable since the way applications interact with notifications is a major point in this potential change). this will probably need a balance between needed capabilities and entry barrier for applications to use it, sending a notification could probably not change much (besides extra data such as what activity it belongs), but something new would be needed for managing the notification lifecycle after is sent... exactly that 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 server can be put into runtime rather easily). Marco is already doing some work on the applet to make it ready to adapt to this new concept. Ideally, the applet will just receive a model of the existing backlog + additional messages for transient notifications and newly spawned persistent ones. What do you think? to repeat to everybody what i said to dario, the notifications applet i'm rewriting, it should be almost ready to be a quite dumb visualization of whatever is the backend. when/if the models of the notifications are ready, so data + exposed actions (delete, execute action foo, mark as read...) are there, even tough not immediate should be quite easy to add this source in the notifications applet. to comment purely on the idea, i would like a lot a more capable notifications system, with stuff like * notifications tied to activities * reliable way to decide when to display the osd popup and when just in the history * when not to archive in the history * when an action can be executed more than once and when doesn't * what should be shown in the history almost forever, what should go after a while probably some of those things can be achieved by extending the current system, some don't, maybe there will be compromises to be done.. that was more or less my wish list to santa tough it's pretty much on the board :) just that 90% of this will happen in the background (server), whereas handlers will just take care of showing a model and a set of events. The aim is to make the client API as simple as possible and have a fatter server. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Notifications-future, a recap
(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. I guess the real question is whether we want to continue with the old paradigm we have or try to bet on something more modern. Also, what I am proposing can still be adapted to interact with other platforms - as I said, the client API should be as minimal as possible and not tied to the complexity of the server. /Sune ___ Kde-frameworks-devel mailing list kde-frameworks-de...@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
