moving KNotification in kdelibs.

[Olivier Goffart]

Le Samedi 19 Novembre 2005 21:02, Lubos Lunak a écrit :
> Dne út 15. listopadu 2005 18:37 Olivier Goffart napsal(a):

>  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

I still have to write a HOWTO with more detailed example,  

Main differences are what i wrote in my original mail
  - Link in popups
  - Context dependent notification (depending in which group is the contact, 
or which folder is the mail)
  - Application may choose when the popup get closed  (after the message has 
been read rather than after a small timeout)

And few others features, like the pixmap in the popup, or the fact it may be 
attached to a widget (not implemented yet)
  
> - 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 i will either remove messagebox notifications, or use a flag in the daemon 
to notify with this medium.

> 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.
Anyway, isn't there already a system daemon responsible to log stuff, that we 
could use ?

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

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.

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


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

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

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

--
Olivier

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051120/057b4d37/attachment.sig>