--nextPart1590704.MsEl7hIyDC
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le Mercredi 23 Novembre 2005 18:45, Lubos Lunak a =E9crit=A0:
> On Sunday 20 of November 2005 12:14, Olivier Goffart wrote:
> > Le Samedi 19 Novembre 2005 21:02, Lubos Lunak a =C3=A9crit=C2=A0:

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

No

>  And yes, they can=20
> 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.=20
> The DCOP interface of KNotify is not really more=20
> 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=
=20
own notification  (i was thinking about systray blinking,  or  making a=20
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 "f=
or
> now" mean that you expect the spec eventually to evolve to what KNotify i=
s?

I was wanting to modify the spec if require to be powerfull with knotify.  =
But=20
not to be KNotify




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




--nextPart1590704.MsEl7hIyDC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDhOrGz58lY8jWrL0RAs6xAJ4xT/zErd/0TES3zMrl7hBgwSuTkgCfZECJ
AvO+m9zOn2zPof3yhaFYDaY=
=6LIV
-----END PGP SIGNATURE-----

--nextPart1590704.MsEl7hIyDC--