Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/sixfold-announcement.html
Let’s have a small poll here: what is the most annoying feature of a modern
GNOME desktop? You got three options to choose from:
- Event sounds, if they are enabled
- Event sounds, if they are enabled
- Event sounds, if they are enabled
Difficult choice, right?
In my pursuit to make this choice a little bit less difficult, I’d like to draw your attention to the following six announcements:
Announcement Number One: The XDG Sound Theming Specification
Following closely the mechanisms of the XDG
Icon Theme Specification I may now announce you the XDG Sound Theme
Specification which will hopefully be established as the future standard
for better event sound theming for free desktops. This project was started by
Patryk Zawadzki and is now maintained by Marc-André Lureau.
Announcement Number Two: The XDG Sound Naming Specification
If we have a Sound Theming Specification, then we also need an XDG Sound Naming
Specification, again drawing heavily from the original XDG
Icon Naming Specification. It’s based on some older Bango work
(which seems to be a defunct project these days), and is also maintained by
Monsieur Lureau. The list of defined sounds is hopefully much more complete
than any previous work in this area for free desktops.
Announcement Number Three: The freedesktop Sound Theme
Of course, what would the mentioned two standards be worth if there wasn’t a
single implementation of them? So here I may now announce you the first
(rubbish) version of the XDG freedesktop
Sound Theme.. It’s basically just a tarball with a number of symlinks
linking to the old gnome-audio event sounds. It’s only a very small
subset of the entire list of XDG sound names. My hope is that this initial
release will spark community contributions for a better, higher quality default
sound theme for free desktops. If you are some kind of musician or audio
technician I am happy to take your submissions!
Announcement Number Four: The libcanberra Event Sound API
Ok, we now have those two specs, and an example theme, what else is missing
to make this stuff a success? Absolutely right, an actual implementation of the
sound theming logic! And this is what libcanberra is.
It is a very small and lean implementation of the specification. However, it is
also very powerful, and can be used in a much more elaborate way than previous
APIs. It’s all about the central function called ca_context_play()
which takes a NULL terminated list of string properties for the sound you want
to generate. How this looks like?
{
ca_context *c = NULL;
/* Create a context for the event sounds for your application */
ca_context_create(&c);
/* Set a few application-global properties */
ca_context_change_props(c,
CA_PROP_APPLICATION_NAME, "An example",
CA_PROP_APPLICATION_ID, "org.freedesktop.libcanberra.Test",
CA_PROP_APPLICATION_ICON_NAME, "libcanberra-test",
NULL);
/* ... */
/* Trigger an event sound */
ca_context_play(c, 0,
CA_PROP_EVENT_ID, "button-pressed", /* The XDG sound name */
CA_PROP_MEDIA_NAME, "The user pressed the button foobar",
CA_PROP_EVENT_MOUSE_X, "555",
CA_PROP_EVENT_MOUSE_Y, "666",
CA_PROP_WINDOW_NAME, "Foobar Dialog",
CA_PROP_WINDOW_ICON_NAME, "libcanberra-test-foobar-dialog",
CA_PROP_WINDOW_X11_DISPLAY, ":0",
CA_PROP_WINDOW_X11_XID, "4711",
NULL);
/* ... */
ca_context_destroy(&c);
}
So, the idea is pretty simple, it’s all built around those sound event
properties. A few you initialize globally for your application, and some you
pass each time you actually want to trigger a sound. The properties listed
above are only a subset of the default ones that are defined. They can be
extended at any time. Why is it good to attach all this information to those
event sounds? First, for a11y reasons, where visual feedback in addition of
audible feedback might be advisable. And then, if the underlying sound system
knows which window triggered the event it can take per-window volumes or other
settings into account. If we know that the sound event was triggered by a mouse
event, then the sound system could position the sound in space: i.e. if you
click a button on the left side of the screen, the event sound will come more
out of your left speaker, and if you click on the right, it will be positioned
nearer to the right speaker. The more information the underlying audio system
has about the event sound the fancier ‘earcandy’ it can do to enhance your user
experience with all kinds of audio effects.
The library is thread-safe, brings no dependencies besides OGG Vorbis (and of
course a Libc), and whatever the used backend requires. The library can
support multiple different backends. Either you can compile a single one
directly into the libcanberra.so library, or you can bind them at
runtime via shared objects. Right now, libcanberra supports ALSA, PulseAudio and a null backend. The library is
designed to be portable, however only supports Linux right now. The idea is to
translate the XDG sound names into the sounds that are native the local
platform (i.e. to whatever API Windows or MacOS use natively for sound events).
Besides all that fancy property stuff it also can do implicit on-demand
cacheing of samples in the sound server, cancel currently playing sounds,
notify an application when a sound finished to play and other features.
My hope is that this piece of core desktop technology can be shared by both
GNOME and the KDE world.
Check out the (complete!) documentation!
Announcement Number Five: The libcanberra-gtk Sound Event Binding for Gtk+
If you compile libcanberra with Gtk+ support (optional), than you’ll get an
additional library libcanberra-gtk which provides a couple of
functions to simplify event sound generation from Gtk+ programs. It will
maintain a global libcanberra context, and provides a few functions that will
automatically fill in quite a few properties for you, so that you don’t have to
fill them in manually. How does that look like? Deadly simple:
{
/* Trigger an event sound from a GtkWidget, will automaticall fill in CA_PROP_WINDOW_xxx */
ca_gtk_play_for_widget(GTK_WIDGET(w), 0,
CA_PROP_EVENT_ID, "foobar-event",
CA_PROP_EVENT_DESCRIPTION, "foobar event happened",
NULL);
/* Alternatively, triggger an event sound from a GdkEvent, will also fill in CA_PROP_EVENT_MOUSE_xxx */
ca_gtk_play_for_event(gtk_get_current_event(), 0
CA_PROP_EVENT_ID, "waldo-event",
CA_PROP_EVENT_DESCRIPTION, "waldo event happened",
NULL);
}
Simple? Yes, deadly simple.
Check out the (complete!) documentation!
Announcement Number Five: the libcanberra-gtk-module Gtk+ Module
Okey, the example code for libcanberra-gtk is already very simple. Can we do
it even shorter? Yes!
If you compile libcanberra with Gtk+ support, then you will also get a ne
GtkModule which will automatically hook into all kinds of events inside a Gtk+
program and generate sound events from them. You can have sounds when you press
a button, when you popup a menu or window, or when you select an item from a
list box. It’s all done automatically, no further change in the program is
necessary. It works very similar to the old sound event code in libgnomeui, but
is far less ugly, much more complete, and most importantly, works for all Gtk+
programs, not just those which link against libgnomeui. To activate this feature $GTK_MODULES=libcanberra-gtk-module must be set. So, just for completeness sake, here’s how the example code for using this feature in your program looks like:
{
}
Yes, indeed. No code changes necessary. You get all those fancy UI sounds for free. Awesome? Awesome!
Of course, if you use custom widgets, or need more than just the simplest
audio feedback for input you should link against libcanberra-gtk yourself, and add
ca_gtk_play_for_widget() and ca_gtk_play_for_event() calls to
your code, at the right places.
Announcement Number Six: My GUADEC talk
You want to know more about all this fancy new sound event world order? Then
make sure to attend my
talk at GUADEC 2008 in Istanbul!
Ok, that’t enough announcements for now. If you want to discuss or
contribute to the two specs, then please join the XDG mailing list.
If you want to contribute to libcanberra, you are invited to join the libcanberra
mailing list.
Of course these six announcements won’t add a happy end to the GNOME sound
event story just like that. We still need better sounds, and better integration
into applications. But just think of how high quality the sound events on e.g.
MacOS X are, and you can see (or hear) what I hope to get for the free desktops
as well. Also my hope is that since we now have a decent localization
infrastructure for our sounds in place, we can make speech sound events more
popular, and thus sound events much more useful. i.e. have a nice girl’s voice telling you “You disc finished
burning!” instead of some annoying nobody-knows-what-it-means bing sound. I am
one of those who usually have there event sounds disabled all the time. My hope
is that in a few months time I won’t have any reason more to do so.