Ayatana notifications for Plasma

[Roderick B. Greening]

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