moving KNotification in kdelibs.

[Olivier Goffart]

Le Mercredi 23 Novembre 2005 18:45, Lubos Lunak a écrit :
> On Sunday 20 of November 2005 12:14, Olivier Goffart wrote:
> > Le Samedi 19 Novembre 2005 21:02, Lubos Lunak a écrit :

>  So? Are you going to dump e.g. logging to a file too? 

No

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

good idea, assing a global shortcut to activate the passive popup.


> [*] 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


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

well, true.

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


>  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.  But 
not to be 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



-------------- 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/20051123/71f3e533/attachment.sig>