Desktop Notifications Spec 0.3
spam at micropp.se
Tue Sep 21 20:47:00 EEST 2004
John (J5) Palmieri wrote:
>On Thu, 2004-09-16 at 16:48 +0100, Mike Hearn wrote:
>>>Shouldn't sound be a part of the spec, too?
>>>I was thinking about gaim, gnomemeeting or the battery monitor for example.
>>Originally it was. But there's no reason not to do this client side, so
>>it was dropped.
>One reason not to do this client side is if you want the audio synced
>with the notification. I don't think it is a big deal not to have it in
>the spec but it would be a nice optional piece since clients would be
>able to decide if they wish to play the sound or have it synced with the
I can see one more use for having sound in the notification spec.
Stuff like 'new email', 'user foo enters chat' etc can be notifed with
sound and/or visual notification. Having sound and a option to tell
that 'sound or notifikation is OK' in the spec make this costomisable in
a central place, good for accessability! IE, For sound notifikations I
want [ ] only sound if avalible, [ ] only popup, [ ] both.
Implementations could have a 'notifikation history' applet, and if sound
notifikations go thru the notifikation server, Users can check what that
stange sound realy was thru the history (or just se what user entered
the chat). If the notifikation have sufisient info about the sending
app, such history cold have a 'bring up app' button for case wher the
app is minimilized or on another virtual desktop.
Even without a notification history we gain that every app need not to
detect if they can play sound. I some time shut down the sound server to
use apps talking to sound device. If that automagicly made gaim
notifikations visual it would be cool!
Now, this shuld of corse only be used for sounds that are notifikation,
not UI feedback like 'toolbutton click sounds'.
More information about the xdg