Desktop Notifications Spec 0.3

Olivier Goffart ogoffart at
Thu Sep 23 18:00:17 EEST 2004

Le Mercredi 22 Septembre 2004 23:45, Christian Hammond a écrit :
> On Wed, Sep 22, 2004 at 02:41:15PM +0200, Lubos Lunak wrote:
> > On Wednesday 22 of September 2004 10:57, Mike Hearn wrote:
> > > I'd veto adding sound back in for such a reason.
> >
> >  You'd veto? Have you been granted a patent on creating a notification
> > spec or something? Sorry, you have no right to veto anything here.
> I would be against it too.

Yes, sounds should be played by the client.  Not in that popup notification 

In KDE, the sound will be played by KNotify.

> I think there's either a misunderstanding in all of this, or
> something.

i think it's pretty complex to see what's the server and what's the client, 
specialy with KNotify which is a client of that spec, but also a server for 
KDE application.

> So perhaps we can reach a compromise. If you want sound playback, the
> server should implement it, and it should not be in the spec. If you
> want your apps to play a custom sound, we'll set up a sound-file hint
> that the server can optionally support.

I would even add a flag to let a default sound or not.
i.e  when the client already play a sound, the server _must_ not play any 
other sound.
but if the client doesn't implements sounds, it could be usefull to have a 
default sound to play in the deamon.  (the same for each popups, configured 
in the server)

(in the KDE server, the "KPopupNotifier" could call KNotify for that default 
sound notification)
I compare that to the  "Notify" flag in the KMessageBox API. So message box  
called by KNotify doesn't go into infinite loop.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the xdg mailing list