moving KNotification in kdelibs.

[Lubos Lunak]

Dne út 15. listopadu 2005 18:37 Olivier Goffart napsal(a):
> Hi Aaron,
> thanks for your remarks.
>
> Le Mardi 15 Novembre 2005 00:46, Aaron J. Seigo a écrit :
> > On Monday 14 November 2005 09:04, Olivier Goffart wrote:
> > > I have developed KNotiofy, a replacement for KNotifyClient
> >
> > is there a rational for replacing KNotify that we could read somewhere?
> > is there some design reference somewhere that one could look at to
> > understand how the client and the server work?
>
> not yet
> I more see that as an evolution rather than a strict replacement.

 If it's actually disguised improved KNotify, then a description of the 
changes would be enough I guess :). I'd like to see something like that too - 
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, 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.

> > and speaking of overhead, what is the overhead of using an external
> > config file in this fashion? in the class docu it mentions "This allows
> > us to play sounds when a dialog appears.", and this should happen pretty
> > much instantly otherwise the system feels slow and clunky.
>
> 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.

> > looking at the code, it seems all the notification actually happens in
> > the client. what is the purpose of the daemon in this case? (i haven't
> > looked at that code at all, ergo the silly question ;)
>
> 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?

> > it also seems that all the notification logic (which type of
> > notification, etc) is contained in the static KNotification::event(...)
> > method for the mapping between the Action type and the actual method
> > calls and the methods that cause actual actions to be takens are all
> > private ... this makes KNotification a fairly well-sealed black box. is
> > there any use case where one might wish to use a KNotification object and
> > call notifyBy* methods themselves? it just seems very non-extensible
> > (though whether it needs to be is the big question i suppose =)
>
> 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?

 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?

> 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"?

-- 
 Lubos Lunak
 KDE Developer
 l.lunak at kde.org     l.lunak at suse.cz