[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Sharing an Event Sound Infrastructure in GNOME and KDE
From:       Lennart Poettering <mzxqr () 0pointer ! de>
Date:       2008-06-10 18:21:14
Message-ID: 20080610182114.GA24392 () tango ! 0pointer ! de
[Download RAW message or body]

Heya K-lovers!

I'd like to draw your attention to the event sound work for free
desktops I just announced on my blog:

http://0pointer.de/blog/projects/sixfold-announcement.html

Basically, for the GNOME world we now have all the necessary infrastructure
in place to make event sounds more enjoyable. I'd like to discuss with
you guys what would be necessary to get KDE to adopt at least the two
specs -- but ideally also the software libcanberra itself. 

The reasons why it would be a good thing to adopt those two specs I
probably don't have to elaborate much about, since you guys adopted
the icon specs. However, why should you adopt libcanberra?

First of all, to increase the amount of code we share between our
desktops. Then, to increase common behaviour of both toolkits:
libcanberra attaches all kinds of meta information to triggered event
sounds. These can be useful for a variety of uses, such as a11y and
"earcandy". If both Qt and Gtk+ would generate its event sounds via
the same library the could be handled the same way by the backend. For
example, if PulseAudio is chosen as a backend it will use the meta
information attached to an event sound to improve presentation to the
user. I.e. if we know that a sound belongs to a window, we can
properly implement per-window volumes. If we have an icon for the
sound, we can show it nicer in the volume control. If we now that it
was triggered by a mouse event we can position the sound in space
(click on a button on the left side of the screen, and the sound comes
from the left speakers, click on the right side of the screen and the
sound comes from the right speakers). Then, libcanberra supports
cacheing of sound samples (including on-demand) on the sound server,
AFAIK KDE doesn't support this right now. However, this is very useful
to have in a thin client environment. The whole properties idea makes
libcanberra very powerful and easily extensible.

Also, I made it easy for you guys to adopt it, it doesn't have any
deps on anything g-ish, just plain libc and vorbis, and whetever the
backend you choose requires. License is LGPL.

What would be necessary to integrate libcanberra in KDE? First of all,
we'd need some way that Qt generates sound feedback for all kind of UI
input events. Clicking a button, popping up a menu or tooltip and so
on. For the Gtk case we do this via a loadable GtkModule and
completely transparently. if the module is not installed you don't get
any sound events, but if you have it installed it just works. I am not
sure if Qt knows something similar to GtkModule, but if you guys do it
would be great if you could make this work similar to the Gtk
case. Alternatively it would be possible to patch Qt itself and
sprinkle the code with calls to ca_context_play() here and there.

Oh, and libcanberra itself is nothing more than an abstraction layer
for event sounds. Hence I don't really think there'd be much point in
adding any further abstraction layers on top of it (which you guys
apparently love to do...). It supports multiple different backends
anyway, and is intended to be portable to other systems, such as
Windows and MacOS (no such backend exists right now, however, only
ALSA/Pulse is supported) So, please don't abstract my abstraction
layer any further, if you should choose to adopt libcanberra.

The current API in Qt that comes closest to what libcanberra can do
for you seems to be QSound. But QSound only supports NAS as backend on
Unix (?) and of course doesn't do any theming stuff. OTOH libcanberra
doesn't support looping right now, while QSound does. (I am happy to
add that to libcanberra, btw, but i think we need something more
elaborate in the end, so i left it out for now)

For the new GNOME event sound world order we decided to trigger sound
events for window-new/close/maximize/minimize and suchlike from the
application itself instead of from the window manager. Why? because
the toolkit tends to know a lot more about the windows it manages than
the window manager. For example it is much easier to trigger the
"dialog-info" sound instead of "window-new" (and not both!) for info
dialogs from inside the Toolkit. Of course, we could export all this
information to the wm too via X properties, but that would be a lot of
additional work. Also most interaction sound events are generated from
the toolkit anyway, so it makes a lot of sense to add those window
new/close/maximize/minimize events to the toolkit too. To make KDE
applications work smoothly in a GNOME environment and vice versa it
would be important that we can agree on which part of the desktop
environment is responsible for those sounds. Also, we'd need to agree
to use a common XSETTINGS option for selecting the sound theme.

Anyway, I am very much interested in getting you guys onto the
boat. I'd like to know your opinions on this, and if there was any
recent work on event sounds in KDE.

It would be best if I could convince you guys to joing the XDG
mailing list for discussion about those two specs, and/or to the
libcanberra ML for discussion about libcanberra.

Thanks for your time,

Lennart, a GNOME hacker

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]