Re: Pulseaudio

[Federico Mena Quintero <federico ximian com>]

On Fri, 2007-10-12 at 21:20 +0200, Lennart Poettering wrote:

[on sounds generated by user events]

>   As soon as I have a version of this library I will write a small
>   module for gtk (the kind of you can load into every gtk app with
>   --gtk-module) which will basically do what libgnome currently does:
>   hooking into a couple of signals -- but instead of direct calls to
>   libesd it will call the aforementioned libcanberra function with the
>   appropriate parameters.

Right now this happens through a rather baroque combination of 

* libgnomeui/gnome-ui-init.c - sets up the signal hooks, reads the
configuration file (which lives in libgnome!).  Monitors GConf for
changes to the "which sound should be played for which event" keys.
Calls into gnome_triggers_vdo(), an evil API which...

* libgnome/gnome-triggers.c - ... was intended to be a generic "hook
into GNOME to do things when interesting stuff happens", which was never
used outside of the event sounds.  Calls directly into ESD to play the
sounds.  Please kill this completely :)

* libgnome/gnome-sound.c - Just initializes the sound connection, I
think, though it also has ultra-simple APIs to play sound files.

If you use a GTK+ module, how will it have the necessary contextual
knowledge to generate all the parameters you want to pass into
libcanberra?  [Is that all contextual information needed?]  The current
code in libgnome[ui] doesn't have that contextual info, either...  It
just knows "a GtkButton was clicked".

If an app wants to give libcanberra more specific information, and so
needs to call cbr_play() directly, how will it keep your GTK+ module
from also playing its own sound?

>From yourexample, what are things like CBR_META_DESCRIPTION and
CBR_META_ICON_NAME for?



  Federico