moving KNotification in kdelibs.

[Lubos Lunak]

On Sunday 20 of November 2005 12:14, Olivier Goffart wrote:
> Le Samedi 19 Novembre 2005 21:02, Lubos Lunak a écrit :
> > Dne út 15. listopadu 2005 18:37 Olivier Goffart napsal(a):

> > - after a quick look at it I actually don't see big conceptual
> > differences from KNotify, besides adding feedback about the notifications
> > (nice) and the strange decision of moving _half_ of the functionality to
> > the client. And I don't see any obvious reason for moving the stuff that
> > is moved, e.g. adding notification in the systray icon would need to be
> > done client-side because the current $%#! systray is client-side, but
> > a) moving dialogs can cause modality and event loop reentrancy problems,
>
> Are dialog still usefull as notification media anyway ?
> Since "passive-popup" may now stay longer , i don't see really the point
> anymore.

 So? Are you going to dump e.g. logging to a file too? And yes, they can still 
be useful. E.g. I myself am not a big fan of passive popups since they are 
passive, so unlike dialogs they don't work with the keyboard.

> > b) moving loging to file
> > can cause problems if more apps log to the same file. Especially since
> > you kept the most complicated part as out-of-process.
>
> But this is to respect the "complicated-passive-popup spec"
> Or we will to have two daemons.

 IMHO you're trying to twist the problem the wrong way. If you really want to 
support this more advanced notification system to that inferior spec[*], why 
are you trying to adapt the more advanced system to the simpler one instead 
the other way around? Two daemons ... why? You can simply have a simple 
client side that'll leave almost everything to the daemon. The daemon will 
handle everything that's needed and additionally can support that spec, by 
having some kind of "backwards" compatibility for it (kinda funny to call it 
backwards when it's newer, but then how'd you call something that's worse?). 

 The knotify daemon can have its own advanced API and additionally have API 
for the spec so that those apps work with it too. That'll save you some 
problems with doing such things locally and you won't have to squeeze the 
more advanced part into the simpler. To support having notifications in other 
desktops using their daemon knotify daemon can detect that and simply map and 
forward things it can do. There will be two daemons in such case but who 
cares, it's not the case you should be optimizing for anyway.

[*] Note that you don't have to support that spec. Just because somebody 
posted it on the fdo mailing list and ignored already existing solutions and 
feedback from others doesn't mean it's a standard or something. What I think 
you really should do is to propose your system as another spec and let the 
better one win. The DCOP interface of KNotify is not really more complicated 
than the spec and it simplifies client side and allows greater flexibility. 
Or you seriously think the spec is better than KNotify?

> Anyway, isn't there already a system daemon responsible to log stuff, that
> we could use ?

 You mean syslog? I don't think KNotify should do system-wide logging.

> > > It has to be in a config file, because the user may configure it.
> >
> >  Not necessarily. The app could send the daemon the description of all
> > the possible events instead of having the daemon read the file that
> > describes them (I think Growl does it this way). If you wanted to gain
> > support for your notification system also from non-KDE people doing it
> > this way would probably make it somewhat simpler.
>
> I don't understand.
>
> Here it is the client which read the config file,  and when a notification
> occurs, it tell the daemon what to do.

 I was talking about the KNotify design when the client side is simple and the 
daemon handles all the details. For a universal notification system having 
configuration in the client side means that it either cannot block stupid 
apps or it has to have the configuration twice. But if you want to keep all 
this KDE-only then nevermind.

>
> > > The deamon is just used to display the popup.
> > > i've tried to implement this specs, which is already used in some gtk
> > > application:  http://www.galago-project.org/specs/notification
> >
> >  The complicated-passive-popup spec. How are you going to handle the fact
> > that they refuse to handle more than one notification type (i.e.
> > popup+sound) but your code does?
>
> Only popup+sound are handled in this daemon
> All the other is done in the client for now.

 I see, they added some kind of sound support eventually, even though 
originally were strictly against if my memory serves me well. Does you "for 
now" mean that you expect the spec eventually to evolve to what KNotify is?

> > > Yes,  i plan to be able to do user event,  and use dirrectly notifyBy*
> >
> >  Why? It's never been used anywhere in KDE with KNotify, and what would
> > be the point of the notifications being configurable then?
>
> It's been used at least in kopete to do context-dependent notification, but
> now, this is not required anymore since KNotification may handle that.
>
> It could be usefull to have it for case we don't think about it yet.

 Then I hope it doesn't make its way in until that case is found. Everything 
can be abused and I bet there'd be somebody who'd be tempted to "simplify" 
things this way instead of using the normal way.

> >  WRT extensibility, what would the Plasma developers have to do if they
> > implemented some oh-so-cool special new notification and wanted to add
> > support for it?
>
> They just have to add support of it in the client library.

 Good luck KDE3 apps won't work with this system anyway so one won't have to 
hack into also KDE3 libs.

> > > void KNotification::raiseWidget(QWidget *w)
> > > {
> > >        //TODO  this funciton is far from finished.
> >
> >  The window manager developer in me feels a bit scared by this. It's not
> > the apps' business to do things like this, besides isn't the whole point
> > of KNotify "XYZ has happened, tell the user, I don't care how"?
>
> While you speek about this, i'll probably need your help for this function.
>
> It will be require since when clicking on the link "view message"  the
> chatwindow with this message should be raised.
>
> And if this is a tabbed window, the correct tab should be shown

 Ah, so this raising is done only after the notification is handled by the 
user? I though it was meant to be part of doing the notification. Then this 
should be no problem of course, I'll help with this if needed.

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