moving KNotification in kdelibs.

[Lubos Lunak]

On Wednesday 23 November 2005 23:18, Olivier Goffart wrote:
> Le Mercredi 23 Novembre 2005 18:45, Lubos Lunak a écrit :
> > On Sunday 20 of November 2005 12:14, Olivier Goffart wrote:
> > [*] 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?
>
> I see this spec as a different thing than KNotify was.
> Just a standard way to show popup.
> This works already fine in Gnome

 Ok, maybe it's just me thinking the spec is technically wrong and you seem to 
think it's fine, but just in the case you want to use this spec only because 
you think it is a standard, then let me stress this:

- just because some gtk apps use that doesn't make it a standard
- even if whole GNOME used it (does it?) that still wouldn't make it a 
standard
- posting it to the xdg at fd.o mailing list doesn't make it a standard
- even listing it among the specifications at fd.o still doesn't make it a 
standard

 And this is not my interpretation, see e.g. 
http://freedesktop.org/wiki/MissionStatement (especially the last paragraph). 
Specifications from fd.o should become de-facto standards when everybody 
starts using them because they see a reason for using them. If you think the 
spec is technically ok, fine. Is it so? It'd be rather sad if everybody 
started using things just because "everybody" else does, regardless of other 
things.

> >  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?
>
> I was wanting to modify the spec if require to be powerfull with knotify. 

 My poor memory may be failing me here, but weren't the authors of this spec 
rather resistant to including any feedback?

> But not to be KNotify

 What's so (technically) wrong with KNotify?

> In general, you begin to convince me to put back most of things in the
> server. But something which is also need to be considred is the cost of a
> dbus call. calls will be done always, even if the notification is
> configured to do nothing.   And there can be lot of "silent" notifications

 Even a pretty slow machine should handle 1000 IPC calls per second just fine. 
And do you expect there ever to be 100 (or even 10) notifications per second? 
Also note that at least some of the common cases may be optimized - e.g. 
current KNotify during startup checks client-side whether there really will 
be any notification for ksmserver and kwin and avoids the calls if not (and 
also avoids launch of the daemon which is the point of this optimization).

> > > 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.
>
> Well, parsing the configuration serverside doesn't let the client doing his
> own notification  (i was thinking about systray blinking,  or  making a
> contact blinking in the contactlist window)

 Contact blinking in the contactlist windows sounds rather 
application-specific, I wonder how you'd want to integrate something like 
this to a generic framework. But anyway, things that need to be done 
client-side could be solved either by always telling the daemon and having 
them both check the settings or having the client ask the daemon if the some 
client-side presentation is configured for the notification. Not that either 
of these is that nice, but who says there are ideal things, one always needs 
to compare advantages and disadvantages.

 I seem to remember two blogs posts that could be relevant and I wonder how 
you'd want to handle them with the client-side approach. I don't really 
remember them well or who wrote them (I'm not ever sure they were really 
blogs posts), but the ideas were 1) notification profiles, 2) notification 
history.

 The first one was something like that if you e.g. are really busy, do a 
KPresenter presentation or whatever, you create another profile and turn off 
all sounds there, don't care about notifications from Kopete, etc. but you 
still want to know important things like low disk space. With daemon taking 
care of the config, you simply switch to another profile there and you're 
done. With things done client-side, you can of course rather simply handle 
the case of KDE apps, but what about non-KDE apps?

 The second case is that after you leave the really-busy mode, you might want 
to review all the missed notifications. The only sensible solution for this I 
can think of is always telling the daemon about an event (and now you have a 
reason to always do the IPC). If you do configuration client-side then the 
user may very well turn off telling the daemon because in such case telling 
the daemon means "show passive popup".

 Especially consider the case that somebody implements something like this 
only for KDE4.2 and not sooner. Or simply think of some idea that might come 
later - e.g. one day it might be nice to have a panel applet queuing all 
notifications instead of them being shown all over the screen. I simply find 
the spec too inflexible and not simpler.

-- 
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/