moving KNotification in kdelibs.
l.lunak at suse.cz
Sat Nov 19 20:02:28 GMT 2005
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"?
l.lunak at kde.org l.lunak at suse.cz
More information about the kde-core-devel