Re: Ayatana notifications for Plasma
On September 30, 2009, Aurélien Gâteau wrote: Aaron J. Seigo wrote: On September 29, 2009, Aurélien Gâteau wrote: Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). Same goes for applets, dataengines... Can an applet unload itself from memory? What I meant with stop itself after a while, was the notify-osd executable calling exit(). I believe your desktop would be a bit too clean if an applet called exit() :). the overhead of a running applet should be negligable unless it's doing something rather wrong. so while you can certainly have an applet remove itself you'd also need a way to re-create it, position it properly, make sure any user adjustments previously made to it remain, etc. then there'd be the overhead of any re- layouts this triggers in the containment, etc. for the memory savings that would result, this probably isn't worth it. I agree. My point was that the perceived bloat of having a separate executable running in the background could be compensated by having said executable stop itself after some time, since DBus would restart it when needed. for a separate process this makes sense; for a widget inside of plasma itself it's probably better not to bother destroying it and recreating it constantly. for clarity, there are three approaches to this: * extensively modify existing upstream widgets, like the system tray * minimal modifications to upstream widgets, provide a new widget that also runs in plasma (as you did with the message thing) * minimal modifications to upstream widgets, run all the new stuff in a separate process i think this conversation may be toggling between the first and last approaches, when there is the middle approach available. this is why i wrote the QScript based system for controlling plasma-desktop. it supports update scripts. there's a file in workspace/plasma/design/ about it and i've blogged about it as well. Oh! I'll forward this to Jonathan. I was thinking about adding a way for kconf_update to run commands before and after updates (so that a script could stop plasma-desktop, edit its configuration and restart it), but this sounds better. at the very least it actually works ;) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Ayatana notifications for Plasma
Sebastian Kügler wrote: Regarding implementing it as a separate applet: I don't think it would have been a good idea because you would have to either add a dumb icon to your panel so that you could run this system, or add an invisible applet (not handy for the user to manipulate). That's what you have the config option for. (it's the same in terms of manipulation right now). I don't understand what you mean. Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). Same goes for applets, dataengines... Can an applet unload itself from memory? What I meant with stop itself after a while, was the notify-osd executable calling exit(). I believe your desktop would be a bit too clean if an applet called exit() :). The alternative of using a kded module could have been a good idea, but it would have required the creation of a kcm to configure the system. Such kcm would have had to tweak Plasma system tray settings behind its back, which could have been a problem to get on the fly changes. It would have at least needed to patch the applet to tell it to stop listening on dbus. You could just as well manipulate the kded module's config from the systray's config dialog. True, but in both cases it would have needed a patch. Offtopic: it's too bad Plasma does not have a DBus call to reload its config. Could be handy when going from one distro release to another (/me thinks about the switch between knetworkmanager the executable and knetworkmanager the plasmoid). I'll try to implement this if I find time. Aurelien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Sebastian Kügler wrote: On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote: I wonder if it would be worthwhile for Sebastian and Aurelien to get together and chat offline. I see some opportunity for clarification in a one-on-one via irc, etc. Not sure, it sounds like you see personal issues between me and Aurelien. I don't. (And I hope Aurelien doesn't either.) I certainly don't have any personal issue with you or any other Plasma dev. Not that I like the current situation with patches that won't be accepted because of different design direction, but to me there's a fundamental difference between Aurelien as a KDE hacker and Aurelien as an Ayatana ambassador. Heh, sometimes I feel like I am suffering from multiple personality disorder :) I believe we had some great discussions at UDS and Sebastian was awesome at helping provide guidance to Aurelien at the time. However, it's possible that over the last 6 months we may have gotten a little off track and we have some opportunity to move this forward in a way desirable to all parties. Or at least, if we cannot make major changes for this release, we can try to minimize any confusion through direction from Sebastion, and look towards doing this differently via USD Lucid and 10.04 release in 6 months time... At UDS, we've discussed doing things in a way that KDE can benefit from work being done by Canonical. I would have hoped that this way, we get things like queueing, prioritizing of notifications and improved layout / display into Plasma upstream (and there's surely room for that). That hasn't happened yet, and I hope it still will. I could probably have spent time trying to get some of the concepts you mentioned integrated to Plasma. I confess I didn't try because I was afraid all of this would be perceived as a sneaky way to move KDE notifications toward Ayatana notifications. Instead I opted for presenting our work as Here is what we did. We believe there are good things in it for KDE. We know you do not agree with some of the core concepts. We would just like you to give it a try and see if you find some ideas interesting for Plasma Aurelien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On Tuesday 29 September 2009 10:34:19 Aurélien Gâteau wrote: Sebastian Kügler wrote: Regarding implementing it as a separate applet: I don't think it would have been a good idea because you would have to either add a dumb icon to your panel so that you could run this system, or add an invisible applet (not handy for the user to manipulate). That's what you have the config option for. (it's the same in terms of manipulation right now). I don't understand what you mean. You could add the invisible applet programmatically if the config option in the systray is set, and remove it in the same way. Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). Same goes for applets, dataengines... Can an applet unload itself from memory? What I meant with stop itself after a while, was the notify-osd executable calling exit(). I believe your desktop would be a bit too clean if an applet called exit() :). Hehe, fluxbox mode. ;-) AFAIK, applets are unloaded from memory when you remove them from the containment. (Though the same version is reloaded, so I guess there's some kind of caching.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Ayatana notifications for Plasma
Hey Aurélien, On Tuesday 29 September 2009 10:52:55 Aurélien Gâteau wrote: Sebastian Kügler wrote: On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote: I wonder if it would be worthwhile for Sebastian and Aurelien to get together and chat offline. I see some opportunity for clarification in a one-on-one via irc, etc. Not sure, it sounds like you see personal issues between me and Aurelien. I don't. (And I hope Aurelien doesn't either.) I certainly don't have any personal issue with you or any other Plasma dev. Good to have this confirmed. Hugs :) Not that I like the current situation with patches that won't be accepted because of different design direction, but to me there's a fundamental difference between Aurelien as a KDE hacker and Aurelien as an Ayatana ambassador. Heh, sometimes I feel like I am suffering from multiple personality disorder :) I can very well understand that. :/ I believe we had some great discussions at UDS and Sebastian was awesome at helping provide guidance to Aurelien at the time. However, it's possible that over the last 6 months we may have gotten a little off track and we have some opportunity to move this forward in a way desirable to all parties. Or at least, if we cannot make major changes for this release, we can try to minimize any confusion through direction from Sebastion, and look towards doing this differently via USD Lucid and 10.04 release in 6 months time... At UDS, we've discussed doing things in a way that KDE can benefit from work being done by Canonical. I would have hoped that this way, we get things like queueing, prioritizing of notifications and improved layout / display into Plasma upstream (and there's surely room for that). That hasn't happened yet, and I hope it still will. I could probably have spent time trying to get some of the concepts you mentioned integrated to Plasma. I confess I didn't try because I was afraid all of this would be perceived as a sneaky way to move KDE notifications toward Ayatana notifications. I think that would actually be a good way forward. Most of the ideas the Ayatana team has WRT notifications are no-brainers IMO. (Streamlined display / layout of the notifications, the stuff that determines how long to show one (current Plasma still doesn't get this right, I often miss the second half of my quassel notifications, queueing (we have very bad bugs when an app goes nuts and stacks 20 notifications on top of each other). All things that would greatly benefit Plasma without diverting from its design concepts. Instead I opted for presenting our work as Here is what we did. We believe there are good things in it for KDE. We know you do not agree with some of the core concepts. We would just like you to give it a try and see if you find some ideas interesting for Plasma -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Ayatana notifications for Plasma
On September 29, 2009, Aurélien Gâteau wrote: Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). Same goes for applets, dataengines... Can an applet unload itself from memory? What I meant with stop itself after a while, was the notify-osd executable calling exit(). I believe your desktop would be a bit too clean if an applet called exit() :). the overhead of a running applet should be negligable unless it's doing something rather wrong. so while you can certainly have an applet remove itself you'd also need a way to re-create it, position it properly, make sure any user adjustments previously made to it remain, etc. then there'd be the overhead of any re- layouts this triggers in the containment, etc. for the memory savings that would result, this probably isn't worth it. The alternative of using a kded module could have been a good idea, but it would have required the creation of a kcm to configure the system. Such kcm would have had to tweak Plasma system tray settings behind its back, which could have been a problem to get on the fly changes. It would have at least needed to patch the applet to tell it to stop listening on dbus. You could just as well manipulate the kded module's config from the systray's config dialog. True, but in both cases it would have needed a patch. Offtopic: it's too bad Plasma does not have a DBus call to reload its config. you really don't want to do that; this implies something other than plasma- desktop has touched the config file(s) but plasma-desktop may have written over it since then. due to limitations in kconfig this whole change the config file on disk behind the app's back is a non-starter. Could be handy when going from one distro release to another (/me thinks about the switch between knetworkmanager the executable and knetworkmanager the plasmoid). I'll try to implement this if I find time. this is why i wrote the QScript based system for controlling plasma-desktop. it supports update scripts. there's a file in workspace/plasma/design/ about it and i've blogged about it as well. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Ayatana notifications for Plasma
Sebastian Kügler wrote: On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote: Aaron J. Seigo wrote: On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. what i'm pretty sure i said (could be wrong, was a # of months ago) was that the option in the system tray could be defaulted very easily to off and the new style of notifications could run separate from it. That was how it was implemented: I splitted notify-osd into a library storing all the logic, and a notify-osd-gtk doing the gtk/cairo rendering. I then implemented a KDE version using Plasma. (You were not the one telling me it was not a good idea, Sebas did) Huh? I pointed out in May during UDS already that you just want to hook in an applet that does the notifications the Ayatana way, and default the systray notifications to off. I was referring to this: http://irclogs.ubuntu.com/2009/05/12/%23kubuntu-devel.txt Search for a separate binary ... oh come on From the very beginning I knew such changes would never be upstreamable, that's why I thought creating a separate binary was the cleanest solution. Regarding implementing it as a separate applet: I don't think it would have been a good idea because you would have to either add a dumb icon to your panel so that you could run this system, or add an invisible applet (not handy for the user to manipulate). Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). The alternative of using a kded module could have been a good idea, but it would have required the creation of a kcm to configure the system. Such kcm would have had to tweak Plasma system tray settings behind its back, which could have been a problem to get on the fly changes. It would have at least needed to patch the applet to tell it to stop listening on dbus. (admittedly, a separate binary would have required a kcm as well) Aurelien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On Monday 28 September 2009 15:03:05 Aurélien Gâteau wrote: Sebastian Kügler wrote: On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote: Aaron J. Seigo wrote: On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. what i'm pretty sure i said (could be wrong, was a # of months ago) was that the option in the system tray could be defaulted very easily to off and the new style of notifications could run separate from it. That was how it was implemented: I splitted notify-osd into a library storing all the logic, and a notify-osd-gtk doing the gtk/cairo rendering. I then implemented a KDE version using Plasma. (You were not the one telling me it was not a good idea, Sebas did) Huh? I pointed out in May during UDS already that you just want to hook in an applet that does the notifications the Ayatana way, and default the systray notifications to off. I was referring to this: http://irclogs.ubuntu.com/2009/05/12/%23kubuntu-devel.txt Maybe the misunderstanding stems from the concept of a separate binary (I mean use an applet). Applets are binaries as well though, so I wasn't clear. Sorry. The context there makes it pretty clear that it should've been done as a separate applet, IMO. As to the cleanest solution, adding a separate notification mechanism is a kludge only done to be able to test those two on the same system. Inevitably, you end up with other kludges to be able to get it in as well (choosing the notification system to be used is one such thing). So that's kind of expected... Search for a separate binary ... oh come on From the very beginning I knew such changes would never be upstreamable, that's why I thought creating a separate binary was the cleanest solution. Fair enough. Self-fulfilling prophecies. :) Regarding implementing it as a separate applet: I don't think it would have been a good idea because you would have to either add a dumb icon to your panel so that you could run this system, or add an invisible applet (not handy for the user to manipulate). That's what you have the config option for. (it's the same in terms of manipulation right now). Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). Same goes for applets, dataengines... The alternative of using a kded module could have been a good idea, but it would have required the creation of a kcm to configure the system. Such kcm would have had to tweak Plasma system tray settings behind its back, which could have been a problem to get on the fly changes. It would have at least needed to patch the applet to tell it to stop listening on dbus. You could just as well manipulate the kded module's config from the systray's config dialog. (admittedly, a separate binary would have required a kcm as well) Nope, KCM != config option somewhere. And where you write out the config is your choice. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Ayatana notifications for Plasma
I wonder if it would be worthwhile for Sebastian and Aurelien to get together and chat offline. I see some opportunity for clarification in a one-on-one via irc, etc. I believe we had some great discussions at UDS and Sebastian was awesome at helping provide guidance to Aurelien at the time. However, it's possible that over the last 6 months we may have gotten a little off track and we have some opportunity to move this forward in a way desirable to all parties. Or at least, if we cannot make major changes for this release, we can try to minimize any confusion through direction from Sebastion, and look towards doing this differently via USD Lucid and 10.04 release in 6 months time... Cheers, Rod. On Monday 28 September 2009 15:03:05 Aurélien Gâteau wrote: Sebastian Kügler wrote: On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote: Aaron J. Seigo wrote: On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. what i'm pretty sure i said (could be wrong, was a # of months ago) was that the option in the system tray could be defaulted very easily to off and the new style of notifications could run separate from it. That was how it was implemented: I splitted notify-osd into a library storing all the logic, and a notify-osd-gtk doing the gtk/cairo rendering. I then implemented a KDE version using Plasma. (You were not the one telling me it was not a good idea, Sebas did) Huh? I pointed out in May during UDS already that you just want to hook in an applet that does the notifications the Ayatana way, and default the systray notifications to off. I was referring to this: http://irclogs.ubuntu.com/2009/05/12/%23kubuntu-devel.txt Maybe the misunderstanding stems from the concept of a separate binary (I mean use an applet). Applets are binaries as well though, so I wasn't clear. Sorry. The context there makes it pretty clear that it should've been done as a separate applet, IMO. As to the cleanest solution, adding a separate notification mechanism is a kludge only done to be able to test those two on the same system. Inevitably, you end up with other kludges to be able to get it in as well (choosing the notification system to be used is one such thing). So that's kind of expected... Search for a separate binary ... oh come on From the very beginning I knew such changes would never be upstreamable, that's why I thought creating a separate binary was the cleanest solution. Fair enough. Self-fulfilling prophecies. :) Regarding implementing it as a separate applet: I don't think it would have been a good idea because you would have to either add a dumb icon to your panel so that you could run this system, or add an invisible applet (not handy for the user to manipulate). That's what you have the config option for. (it's the same in terms of manipulation right now). Keep in mind that the binary is started on demand, so it does not take any memory if you are not using it (assuming it would automatically stop itself after a while). Same goes for applets, dataengines... The alternative of using a kded module could have been a good idea, but it would have required the creation of a kcm to configure the system. Such kcm would have had to tweak Plasma system tray settings behind its back, which could have been a problem to get on the fly changes. It would have at least needed to patch the applet to tell it to stop listening on dbus. You could just as well manipulate the kded module's config from the systray's config dialog. (admittedly, a separate binary would have required a kcm as well) Nope, KCM != config option somewhere. And where you write out the config is your choice. 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: Ayatana notifications for Plasma
On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote: I wonder if it would be worthwhile for Sebastian and Aurelien to get together and chat offline. I see some opportunity for clarification in a one-on-one via irc, etc. Not sure, it sounds like you see personal issues between me and Aurelien. I don't. (And I hope Aurelien doesn't either.) Not that I like the current situation with patches that won't be accepted because of different design direction, but to me there's a fundamental difference between Aurelien as a KDE hacker and Aurelien as an Ayatana ambassador. I believe we had some great discussions at UDS and Sebastian was awesome at helping provide guidance to Aurelien at the time. However, it's possible that over the last 6 months we may have gotten a little off track and we have some opportunity to move this forward in a way desirable to all parties. Or at least, if we cannot make major changes for this release, we can try to minimize any confusion through direction from Sebastion, and look towards doing this differently via USD Lucid and 10.04 release in 6 months time... At UDS, we've discussed doing things in a way that KDE can benefit from work being done by Canonical. I would have hoped that this way, we get things like queueing, prioritizing of notifications and improved layout / display into Plasma upstream (and there's surely room for that). That hasn't happened yet, and I hope it still will. For some points, such as actions on notifications, there doesn't seem much wiggle room on either side. We've talked about this over and over, and it's also where people get annoyed. Wrong focus, IMO. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Ayatana notifications for Plasma
On Monday 28 September 2009 17:01:34 Roderick B. Greening wrote: I wonder if it would be worthwhile for Sebastian and Aurelien to get together and chat offline. I see some opportunity for clarification in a one-on-one via irc, etc. Not sure, it sounds like you see personal issues between me and Aurelien. I don't. (And I hope Aurelien doesn't either.) Not that I like the current situation with patches that won't be accepted because of different design direction, but to me there's a fundamental difference between Aurelien as a KDE hacker and Aurelien as an Ayatana ambassador. God no. I certainly wasn't implying any issues. I think the co-operation is awesome. I was just thinking instead of a mailing list discussion, a real time chat may be more productive. I apologize if I inadvertently made it sound otherwise :) I believe we had some great discussions at UDS and Sebastian was awesome at helping provide guidance to Aurelien at the time. However, it's possible that over the last 6 months we may have gotten a little off track and we have some opportunity to move this forward in a way desirable to all parties. Or at least, if we cannot make major changes for this release, we can try to minimize any confusion through direction from Sebastion, and look towards doing this differently via USD Lucid and 10.04 release in 6 months time... At UDS, we've discussed doing things in a way that KDE can benefit from work being done by Canonical. I would have hoped that this way, we get things like queueing, prioritizing of notifications and improved layout / display into Plasma upstream (and there's surely room for that). That hasn't happened yet, and I hope it still will. Exactly the sort of discussion I believe we need to have. I'm sure everyone is up for that. For some points, such as actions on notifications, there doesn't seem much wiggle room on either side. We've talked about this over and over, and it's also where people get annoyed. Wrong focus, IMO. I agree. There will be some ways in which we will differ. I see the end game for Kubuntu and KDE is to hopefully see this experiment and maybe take some ideas to help improve notifications in KDE in general. Obviously some things do not fit with KDE from Ayatana, but some others would definitely help if carried over to KDE in some fashion. 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: Ayatana notifications for Plasma
On Thursday 24 September 2009 09:16:25 Aurélien Gâteau wrote: Aaron J. Seigo wrote: On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. what i'm pretty sure i said (could be wrong, was a # of months ago) was that the option in the system tray could be defaulted very easily to off and the new style of notifications could run separate from it. That was how it was implemented: I splitted notify-osd into a library storing all the logic, and a notify-osd-gtk doing the gtk/cairo rendering. I then implemented a KDE version using Plasma. (You were not the one telling me it was not a good idea, Sebas did) Huh? I pointed out in May during UDS already that you just want to hook in an applet that does the notifications the Ayatana way, and default the systray notifications to off. It is not a 100% clear from the spec that has been written as result of those meetings ( https://wiki.kubuntu.org/KubuntuKarmicAyatana ), but I'm 100% sure I told you and other people from your team (David, Rick) that Ayatana can be done without upstream code changes, just adding an extra applet. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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: Ayatana notifications for Plasma
Hi, I for one was one of the early skeptics, being a supporter of keeping Kubuntu as much a pure KDE dist as possible. Part of our goal was to allow Canonical to trial their new notifications under KDE, while defaulting to pure KDE notifications, thus permitting the user the choice to test out this experiment by opting in. I believe this was a good decision, in that it allowed the Kubuntu team to maintain its goals, yet at the same time, allowed some experimentation with new ideas. After having opted into the trial, I have found that these new notifications are quite appealing, and coupled with the Notification Indicator Applet that Aurélien has written, I find that I am having a much better user experience. I do believe that while KDE may not desire to merge the patches for this, it is definitely worth a look to see what ideas may be taken from this experiment, and possibly something to consider as ideas for integration into KDE 4.4 or 4.5. The click-through on notifications are simply beautiful, and allow the user to continue to type behind the pop-up and thereby not interrupt work flow. Anyway, just to give a users perspective.. Regards, Rod. Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi l.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.p ng An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried for one to make an informed opinion on it. The feedback I got from Kubuntu Karmic users is varied: some like it a lot, other don't. Please let me know your opinion on this. Regards, Aurélien 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: Ayatana notifications for Plasma
Am Mittwoch 23 September 2009 16:48:00 schrieb Aurélien Gâteau: Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. That just saved you from a rant about it on planetkde from my side ;-) I wanted to blog about some things I don't like. Most important I don't like that Canonical is reinventing the wheel. KDE has a great notification system which could be improved but developing a second system is IMHO completely wrong and doesn't look like a good Upstream/Downstream relationship. An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png Sorry have you ever considered how that looks to the user? Which user does know about Ayatana? That is a technical term which should not be presented in a UI. Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't (btw the last time I tested Karmic the edges monitor didn't get disabled when switching to KDE notifications). If you wanted to give an easy way to test this system while not destroying user experience you should have made this a hidden config file option. Some personal notes: adding strings to the user interface is realy bad if the distribution is Kubuntu. From my experience of four years using Kubuntu there has never been any release where the custom additions made by Kubuntu were translated and given the history and the fact that there is no community left which will translate the strings I doubt they will be translated. There is IMHO nothing worse to the user experience than broken translations. That's of course in no way your fault, I just wanted to make you aware of the problem ;-) And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. There might be good things about it and it would be great to bring them into the normal KDE notifications but all together I don't want the system. I have spoken to many Ubuntu users and nobody has said a good word about notifiy-osd, the most common saying was broken by design. Just so when Kubuntu switches to Ayatana, I will switch to a different distribution. I don't want a distribution which doesn't use the upstream implementation in a very centric part of the desktop environment. 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: Ayatana notifications for Plasma
Martin Gräßlin wrote: An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png Sorry have you ever considered how that looks to the user? Which user does know about Ayatana? That is a technical term which should not be presented in a UI. I was thinking just like you. My initial patch was labeled Lighter notifications, but Celeste and ScottK (of Kubuntu fame) suggested to put the Ayatana word here to start building a brand on it. Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. (btw the last time I tested Karmic the edges monitor didn't get disabled when switching to KDE notifications). Good point. Will fix. If you wanted to give an easy way to test this system while not destroying user experience you should have made this a hidden config file option. I would not call this an easy way to test And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. There might be good things about it and it would be great to bring them into the normal KDE notifications but all together I don't want the system. That's all I want you to find. Experiment with it and extract anything which makes sense from it. I have spoken to many Ubuntu users and nobody has said a good word about notifiy-osd, the most common saying was broken by design. As I said, the changes received varied feedback. I met Ubuntu users who really loved notify-osd, and others who don't. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Disclaimer: this mail is not meant to sound offensive and/or personal. On Wednesday 23 September 2009 16:48:00 Aurélien Gâteau wrote: Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. I'd like a bit more clarity. The patch you posted about powerdevil was presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. I don't want to go off-topic or whatever, since about your PowerDevil patch I am quite confused as I really can't decide between a notification and a dialog, but I'd just like to have some clarifications on purpose and goals. That said. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. What about IM? Without what you presented in your post about Indicators, the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different kind of notifications (with 2 API and 2 underlying systems) the developer has to choose (and learn) to display informations. And the situation of PowerDevil is the one that demonstrates the weakness of this design. Putting aside the scope of the notification, the side effects and whatever, my question is: would it be possible, with the current Ayatana spec featuring indicators to achieve something like powerdevil notification without a dialog? I bet the answer is no. Indicators would be too much, and with this spec you are defining (IMHO) the following points: 1 - Everything that requires user interaction can be delayed until X - wrong. Unless you decide that in situations where the user has to provide fast feedback you want to use dialogs 2 - Everything short-noticed should be passive - wrong. It's instant messaging for a reason :) Indicators might fit for mails, but if I'm using an instant messenger I want to see the message on the fly, be able to view it if I want (by clicking the notification), or simply let it fade out. So it looks like this design is lacking a middle-way of doing things. Aside from that, having 2 (!) servers handling notifications is what I call bloat. Especially now that we're targeting small devices where powersaving and resource consumption DO matter. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. Nice indeed, but is that what the user expects? What if the user wants simply to close it without waiting for the timeout? - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi l.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.p ng An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried
Re: Ayatana notifications for Plasma
Am Mittwoch 23 September 2009 18:21:32 schrieb Aurélien Gâteau: Martin Gräßlin wrote: An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/config ura tion.png Sorry have you ever considered how that looks to the user? Which user does know about Ayatana? That is a technical term which should not be presented in a UI. I was thinking just like you. My initial patch was labeled Lighter notifications, but Celeste and ScottK (of Kubuntu fame) suggested to put the Ayatana word here to start building a brand on it. Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. No I didn't and tried it. But still it just shows that it is a different style. It doesn't show anything about the different functionalities. It's just a small preview it's not usage, like a Kopete notfication or a Suspend notification. (btw the last time I tested Karmic the edges monitor didn't get disabled when switching to KDE notifications). Good point. Will fix. If you wanted to give an easy way to test this system while not destroying user experience you should have made this a hidden config file option. I would not call this an easy way to test An easy way to experiment for advanced users while not breaking setups for beginners. And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. Well maybe the French community is better. But for Germany there is no such thing as a translator for Kubuntu any more. Rosetta did a good job on that :-( Obvious strings like Select System Language in the Language KCM is still untranslated for years. But that's OT. There might be good things about it and it would be great to bring them into the normal KDE notifications but all together I don't want the system. That's all I want you to find. Experiment with it and extract anything which makes sense from it. I have spoken to many Ubuntu users and nobody has said a good word about notifiy-osd, the most common saying was broken by design. As I said, the changes received varied feedback. I met Ubuntu users who really loved notify-osd, and others who don't. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Ayatana notifications for Plasma
Martin Gräßlin wrote: Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. No I didn't and tried it. But still it just shows that it is a different style. It doesn't show anything about the different functionalities. It's just a small preview it's not usage, like a Kopete notfication or a Suspend notification. The KDE notification has an action, the Ayatana one does not. The Ayatana one also has text explaining how to play with it. And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. Well maybe the French community is better. But for Germany there is no such thing as a translator for Kubuntu any more. Rosetta did a good job on that :-( Was not talking about translations here. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Am Mittwoch 23 September 2009 18:50:41 schrieb Aurélien Gâteau: Martin Gräßlin wrote: Why should a user switch to something else than the KDE notifications? The dialog is completely missing any information on what the notifications provide, what's the difference between the two and in the end it will come down to the one provides different possible positions while the other doesn't It seems you missed the Preview buttons in the dialog. No I didn't and tried it. But still it just shows that it is a different style. It doesn't show anything about the different functionalities. It's just a small preview it's not usage, like a Kopete notfication or a Suspend notification. The KDE notification has an action, the Ayatana one does not. The Ayatana one also has text explaining how to play with it. Exactly and I don't think this is obvious to the user. Yes the KDE preview does show the action while the Notify OSD doesn't. But can you expect that the user will notice that there won't be actions? That's what I meant with showing a Kopete notification. You will only notice the missing action when you want to click on it to jump to your Kopete instance. And that's something you can't show in a preview as it is out of context, out of the workflow. And I am realy afraid that there will be the time when Kubuntu switches from KDE notifications to those Ayatana notifications. I realy hope that will never happen. My knowledge of the Kubuntu community makes me quite confident this won't happen. Well maybe the French community is better. But for Germany there is no such thing as a translator for Kubuntu any more. Rosetta did a good job on that :-( Was not talking about translations here. Ups sorry, mixed it up :-( Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Ayatana notifications for Plasma
On September 23, 2009, Dario Freddi wrote: presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. of course it is strictly related. that this wasn't made obvious in the posting to kde-core-devel is a little odd but also completely what i've come to expect. i didn't really feel like going into on kde-core-devel because i don't think there's anything to gain at this point, but it's no surprise that the people who felt it necessary to come up with such a patch are the people who have removed actions from notifications. 2 + 2 = 4. the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. now, whether anyone else outside of Canonical thinks it is better or worse seems to really not matter. any discussion on it is therefore a waste of time. and i'd prefer not to waste our time on this list. btw, i'd recommend to anyone using the Ayatana notifications patch not do so on a laptop running on battery power if you care about getting the most out of a battery charge. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Ayatana notifications for Plasma
Dario Freddi wrote: I'd like a bit more clarity. The patch you posted about powerdevil was presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. I don't want to go off-topic or whatever, since about your PowerDevil patch I am quite confused as I really can't decide between a notification and a dialog, but I'd just like to have some clarifications on purpose and goals. I wrote the Powerdevil patch because the notification annoyed me a few times ago personally, but also because it was a problem for Ayatana notifications. Note that with Ayatana notifications, I mean either notify-osd or the Plasma patch I posted. I should have mentioned it in my first message, and I addressed this (probably not enough) in one of the answers I made to Aaron, where I mentioned the Powerdevil notification was a bigger problem for Kubuntu users running notify-osd. I have been preparing the email about Ayatana notifications for a few days and wanted to keep them separate, but when I read Sebas mentioning Ayatana notifications, I decided to rush it out because as I said, I thought it would be more correct if I presented this work to the Plasma devs myself. I am sorry for this bad timing. I really did not try to have the Powerdevil patch upstreamed before presenting the Ayatana patch. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. What about IM? Without what you presented in your post about Indicators, the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different kind of notifications (with 2 API and 2 underlying systems) the developer has to choose (and learn) to display informations. Yes, the indicators are meant to complement the passive notifications. And the situation of PowerDevil is the one that demonstrates the weakness of this design. Putting aside the scope of the notification, the side effects and whatever, my question is: would it be possible, with the current Ayatana spec featuring indicators to achieve something like powerdevil notification without a dialog? I bet the answer is no. Indicators would be too much, and with this spec you are defining (IMHO) the following points: 1 - Everything that requires user interaction can be delayed until X - wrong. Unless you decide that in situations where the user has to provide fast feedback you want to use dialogs 2 - Everything short-noticed should be passive - wrong. It's instant messaging for a reason :) Indicators might fit for mails, but if I'm using an instant messenger I want to see the message on the fly, be able to view it if I want (by clicking the notification), or simply let it fade out. This was my exact feelings before giving the passive notifications a try. What I realized is that active notifications introduce a urge to act: you must act by clicking the button before the notification goes away. If you are using passive notifications plus a system like the indicators, you do not have this urge to act: you can read the IM text of the notification and take your time to act because the indicator will provide you a permanent access to the incoming chat message. So it looks like this design is lacking a middle-way of doing things. Aside from that, having 2 (!) servers handling notifications is what I call bloat. Especially now that we're targeting small devices where powersaving and resource consumption DO matter. They are just applets listening to DBus communications. I would not call this bloat (what I would call bloat is not having indicators and implemented in term of systray, but that's another story). On a really small device, neither KDE nor Ayatana notifications will fit the needs anyway. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. Nice indeed, but is that what the user expects? What if the user wants simply to close it without waiting for the timeout? The need to close is usually motivated by the need to reach what is under the notification. Using it for a while I did not felt the need to close them. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On Wed, Sep 23, 2009 at 1:08 PM, Aaron J. Seigo ase...@kde.org wrote: On September 23, 2009, Dario Freddi wrote: presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. of course it is strictly related. that this wasn't made obvious in the posting to kde-core-devel is a little odd but also completely what i've come to expect. i didn't really feel like going into on kde-core-devel because i don't think there's anything to gain at this point, but it's no surprise that the people who felt it necessary to come up with such a patch are the people who have removed actions from notifications. 2 + 2 = 4. the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. The Ayatana notifcations are installed by default but not configured by default in Kubuntu Karmic for *testing* purposes (this wasn't clear in Aurelian's email). We (Kubuntu) didn't want to provide it by default and adding a configuration option was a compromise we made with the Canonical Design team who wanted to see how the system works for KDE users used to actions in notifications (not really the best evaluation method, but whatever). If it ends up that the Ayatana notifcations fail in a major way, then the configuration option and functionality will (in theory) be removed from defaults (but users will still be able to install as an addon it if they want). Canonical did a really bad job involving upstreams in the design process and are now trying to make up for it by keeping upstreams aware of what is going on. It may be too little too late, but if we (KDE) can at least humor them, then they will be more willing to listen how they can make their software work better with KDE (even if it doesn't follow what KDE wants to do) instead of just forcing Kubuntu to ship whatever they produce. -- Celeste Lyn Paul KDE Usability Project KDE e.V. Board of Directors www.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
Aaron J. Seigo wrote: On September 23, 2009, Dario Freddi wrote: presented as your initiative regardless of Ayatana. However, with Ayatana notifications user interaction is not possible, hence your previous patch was either an unfortunate wrong timing coincidence or strictly related. of course it is strictly related. that this wasn't made obvious in the posting to kde-core-devel is a little odd but also completely what i've come to expect. i didn't really feel like going into on kde-core-devel because i don't think there's anything to gain at this point, but it's no surprise that the people who felt it necessary to come up with such a patch are the people who have removed actions from notifications. 2 + 2 = 4. I just explained myself about this in my answer to Dario. As I said it was poor timing and I recon I should have been handled this in a different way. the desktop workspace would be broken. Hence this makes me really believe you're taking the wrong route here. You are basically pushing 2 different before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. I try to reach out with this mail. If we were not looking for outside participation, you would not find me regularly trying to upstream changes. And things can change too. For example the more I think about indicators, the more I believe you are right in that they should be implemented in terms of an evolution of the system tray. Getting other members of my team to think the same is another story... btw, i'd recommend to anyone using the Ayatana notifications patch not do so on a laptop running on battery power if you care about getting the most out of a battery charge. I guess you mean I made a stupid mistake in my code. Can you explain what it is? Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On Wednesday 23 September 2009, Aurélien Gâteau wrote: Hi, I would like to present to you some work I have been doing for Canonical regarding notifications in Plasma. Before going further, let me state that my goal with this mail is not to get this work incorporated upstream, as I understand the Plasma project have a different position than Canonical on the subject of notifications. I decided to write this mail because I believe it is more correct to let you know about it in a more personal way rather than you discovering it in a blog post or a Kubuntu review. This work provides an implementation of Ayatana notifications for Plasma (Ayatana is the name of a Canonical project to improve user experience on Ubuntu and derivatives). Ayatana notifications have the following characteristics: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications - Notifications are queued instead of stacked. This helps reduce the spamming feeling. - Notifications are passive: they do not feature actions or close buttons. This is probably the most controversial bit. - Since notifications are passive, they are click-through: when you move the mouse over them, they fade away to become almost transparent and let you click through them to reach any underlying window. - Since they do not need any interactivity interface, they are drawn using Plasma tooltip SVG. Here are (slightly outdated) screenshots of what they look like: http://people.canonical.com/~agateau/plasma-ayatana-notifications/powerdevi l.png http://people.canonical.com/~agateau/plasma-ayatana-notifications/kopete.pn g An important point: While the patch is integrated in Kubuntu, the default behavior is to use KDE notifications. The user can switch to Ayatana notifications through an option of the system tray configuration dialog (there are even preview buttons to help the user decide). http://people.canonical.com/~agateau/plasma-ayatana-notifications/configura tion.png I attached a patch for you to test if you feel so inclined. I updated it this morning to latest trunk. It is a single large patch because I believe it is easier to try it this way, but if you are interested in the incremental steps, you can find a patchset tarball here: http://people.canonical.com/~agateau/plasma-ayatana-notifications/ As I said I do not expect this to be merged but I would be very happy if some of you just gave it a try for a few hours and maybe find some interesting ideas in it. The queuing and click-through features in particular could be interesting. I was quite skeptic about the idea of passive notifications first, but have since changed my mind after using them for a while. I believe this new approach needs to be tried for one to make an informed opinion on it. The feedback I got from Kubuntu Karmic users is varied: some like it a lot, other don't. Please let me know your opinion on this. Regards, Aurélien -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo wrote: before this gets carried forward into a big thread on this list, it has been made very clear that Canonical is intent on following through on these ideas as they are. it is an insular project without outside participation, which is something they are perfectly free to engage in and i fully support their right to do so. I try to reach out with this mail. If we were not looking for outside participation, you would not find me regularly trying to upstream changes. sending patches and saying hey, this is what we're doing when there is no intention of modification of the design or harmonizing it with the work of those you are sending the patches to is only notification of your work (excuse the pun ;). that is more than some do, and i appreciate that. it is not, however, an invitation to the outside to participate on working on the design your patches espouse. (where your refers to Ayatana, not you personally :) that is a completely fair and reasonable thing for Ayatana to do, but it does make Ayatana insular and closed to true outside participation. by contrast, the design of Plasma itself has been formed and influenced by a large number of people, almost all of whom have self-selected and have entered into the core of the project simply through their efforts rather than my express permission. on the matter of notifications, we have a fundamental difference in design and expectations and simply showing each other our code isn't going to change that. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Ayatana notifications for Plasma
On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: Ayatana notifications for Plasma
Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ayatana notifications for Plasma
On September 23, 2009, Aurélien Gâteau wrote: Aaron J. Seigo a écrit : On September 23, 2009, Marco Martin wrote: every other consideration aside, i feel that it would have been -far- easier to mantain if the systray patch just consisted in notifications disabling and provide a totally separate daemon for that kind of notifications unless i'm misremembering things, this is also what i suggested to the people working on this when the Ayatana notifications design was first announced. My first implementation was doing exactly this. But I was told (by a Plasma dev) it was not a good idea. what i'm pretty sure i said (could be wrong, was a # of months ago) was that the option in the system tray could be defaulted very easily to off and the new style of notifications could run separate from it. it could make sense to share the notifications DataEngine, depending on how that part was written, but modifications to the systray widget should not have been necessary. i pointed out (i think to Bo?) that the systray was designed to easily get out of the way of notifications and that one could watch for the notifications host dbus service becoming available. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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
