Re: Pulseaudio

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 15.10.07 02:24, Federico Mena Quintero (federico ximian com) wrote:

> >   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".

The basic idea was to just copy libgnome's behaviour. Seemed good
enough for me, for now. Of course, there's always room for
improvement, but I didn't want to get side-tracked too much.

The nice thing is that since this is just a gtk module not many people
will ever see how baroque it actually is ;-)

> 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?

This is a good question. Maybe we can add some kind of property to
attach to widgets which tells my libcanberra-gtk-bridge-as-gtk-modul
thing to not do its thing for this widget, possibly even with a
bitmask to disable specific event sounds, but not all.

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

If the event sounds are shown in the volume control, they should be
shown with what they actually mean. Also, besides each stream a small
icon should be shown to help identifying the event sound in
question.

This might also be useful a11y, i.e. to show a textual notification
instead of a sound. Admitedly I don't have too much insight into a11y,
but at least for stuff like event sounds for completion of long
running actions (i.e. "CD burning completed", "Download completed") it
might make sense to disable event sounds and use a notification window
instead for a11y. Of course, this somewhat plays into the area
libnotify is being used for already -- without the need for anything
like libcanberra.

The basic idea of that snippet was to show just a few random
properties that might be useful to attach to an event
sound. Definining which ones actually make sense, and which ones don't
is a different issue. And more a policy decision then a technical
decision.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4