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.
