Re: [gpm] Sound Event Control

[Ted Gould <ted ubuntu com>]

On Thu, 2008-03-13 at 13:48 -0400, David Zeuthen wrote:
> On Thu, 2008-03-13 at 08:42 -0700, Ted Gould wrote:
> > So I've gotten the request for finer-grained sound event control in GPM..
> > Which makes sense.  The code is nicely contained in gpm-sound.c, so it
> > should be an easy patch... the question comes down to how should it be
> > implemented.  A GConf boolean for each sound event (lid close, open,
> > etc.)?  A key that has the path to the sound file so potentially someone
> > could change it later? (with some way to signify "none")
> 
> I'd really really hate to see this the preferences UI polluted with
> options like these. Also, throwing options at a problem is rarely the
> right solution; my understanding is that g-p-m only make audible noise
> on error conditions. Or did the feature-creep-monster change that at
> some point?

That was my first reaction too :)

The event that is of immediate concern here is the lid open sound.  If
you're going to a talk and you shut your laptop before going, but forgot
to mute the sound, you'd be in a tough spot.  It seems for most people
this sound isn't really useful.

> Also, there's a fair bit of work being planned about how sound events
> are going to work in the future in GNOME (see the desktop-devel-list
> archives) and each app hardcoding the file names is, IIRC, not part of
> it (we want themable sound events name for starters so we at least have
> *some* chance of sorting our the sound events mess).

I've seen lots of e-mail, but nothing seriously solid, and no code.  I
haven't seen anything come across the xdg-list either, which is probably
where it should start.  So, while I agree with your sentiment, it's not
something that I can solve a bug with today.

I'm thinking about taking the brute force approach of disabling the lid
open, close and ac remove sounds in the C code with a patch.  While
drastic, I'm unsure with a more creative path.

		--Ted