Ayatana notifications for Plasma

Aurélien Gâteau 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
>>>>> 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:


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)


More information about the Plasma-devel mailing list