Ayatana notifications for Plasma

[Sebastian Kügler]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090928/e863325b/attachment.sig