Re: gnome-triggers/gnome-sound/sound events

[Bill Haneman <bill haneman sun com>]

Havoc Pennington wrote:
> 
> Bill Haneman <bill haneman sun com> writes:
> > Elliot Lee wrote:
> > >
> >
> > > When programs want to generate a .soundlist type of sound event (such as
> > > "button clicked" or whatever) they ask gnome-session (via
> > > gnome_client_app_event()) to make it happen.
> > >
> > > So aside from s/gnome_triggers_do/gnome_client_app_event/, there's no
> > > change from the app's viewpoint (and not many apps use this API anyways).
> > > The main gain is from removing the dependency of tons of apps on libesd
> > > and libaudiofile, to decrease startup time, memory footprint, and
> > > dependencies in general.
> > >
> > > -- Elliot
> >
> > This has the added benefit of making it easy to support alternate,
> > non-audio 'notifications' if the audio file is actually conveying
> > (non-redundant) information.  This is good for accessibility for
> > hearing impaired (and the audio-driver-impaired ;-)
> >
> 
> If we're going to start packing things in, then the part in
> gnome-session needs to be kept bounded and minimal; maybe
> gnome-session would just pass notification along to yet another
> process. i.e. gnome-session could be just a switchboard, it doesn't
> run the actual code that plays the sound or whatever.

OK, whatever we do, we should avoid having the apps hard-code a "play"
command to a sound engine if the purpose of the sound is
notification.  Somewhere there needs to be a "notification sound" API,
even if it's not in gnome-session.

-Bill

-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland