Ayatana notifications for Plasma
aurelien.gateau at canonical.com
Mon Sep 28 15:03:05 CEST 2009
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
>>>> 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
I was referring to this:
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
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)
More information about the Plasma-devel