Re: Request for Comments: GNOME Notifier

[Lubos Lunak <l lunak suse cz>]

On Thursday 29 of July 2004 22:48, Mike Hearn wrote:
> On Thu, 29 Jul 2004 13:33:14 -0700, Christian Hammond wrote:
> >> It seems that the main  change  required for them is to use DBUS instead
> >> of a DCOM mechanism to call the server, and then move to the new spec if
> >> they like it. is that the only stone in the way?
> >
> > That, and we'd need code to listen in on our notification D-BUS
> > service and relay it to KNotify.
>
> I've been thinking more about this, and KNotify isn't really a good
> semantic match. If you look at the API docs it's really a lot more
> generic, codes presentation styles into the API and so on.

 Yes, the semantics don't quite match as far as I can tell. And after reading 
the "backwards compatibility" section talking about KNotify I have a slight 
suspicion that you misunderstood how KNotify works (because I just don't see 
what the contents of that section have to do with KNotify). I'm not KNotify 
expert, but it works roughly like this:

 The only usually used function is KNotifyClient::event(), if you grep e.g. 
Konsole, that's the only one it uses. When an app wants to notify about some 
event, it simply only calls event() with event type and event message. There 
are configuration files specifying default presentation type for each event 
type. When knotify daemon receives notification event, it checks the 
configuration and represents the event according to it. If the user wants a 
different kind of notification for some events, they can go to KControl or in 
the app in menu Settings->Configure notifications, and can change it or turn 
it off completely.

 There's currently no way to get feedback from the daemon, so KNotify 
currently can only do informational notifications, but that could be added. 
Kopete seems to have its own extended version which supports feedback, that 
should be moved to the kdelibs version.


> I think a better approach would be to just have a simple proxy app (or KDE
> backend to the current notification-daemon ref impl) which uses
> KPassivePopup directly. That way you get KDE UI, a C++ backend which I
> think they may like ... KNotify isn't used under the hood but as far as
> the user is concerned the experience is very similar.
>
> Lubos, any thoughts on that?

 I said I'm no KNotify expert, but although the proposal has some things 
KNotify doesn't, like the feedback, it seems to be less flexible to me than 
KNotify.

 With KNotify, if KFoo by default uses passive popup and a beep-beep sound for 
even "foo happened", I can turn it off, change it to a normal dialog or just 
make the apps taskbar blink if I want, simply because the app only does 
event( "foo happended event", "Yes, it did."), and the framework handles the 
rest. In the proposal it's the app specifying the sound or urgency (and I 
don't see it talking about any other form other than passive popup), so if I 
want it differently, I out of luck. It should be simple to add it to the 
proposal though.

 That said, if you want to have a generic system, shouldn't this discussion be 
moved to the xdg@ mailing list? There was a similar thread on kde-core-devel@ 
recently, so probably there should be some KDE devels interested in this.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/