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