Re: [Usability] sound events in gnome

[Rodney Dawes <dobey novell com>]

On Mon, 2005-09-26 at 12:16 +0200, Sven wrote:
> Hi list,

> The tab "Sound events" opens up much to small, and every section is opened
> by default - games on top. Most time i dont want to change the
> gnome-game-sounds. I want to change start sounds or warning sounds. They
> have to be on top in that list due to importance.

Game sounds should not be customizeable outside the games at all I
think. Game sounds are typically specific to the game type and the
actions and events in it. I believe they are there simply due to
historic reasons so that they could use the sound events API to play
the sounds.

> Why are only so few options in the "Sound events"-dialog, lots of projects
> like gaim have their own sound-selection dialogs because the gnomes one is
> so bad and doesnt integrate well. Come on guys you have gconf, why dont you
> use that?

Gaim has their own sound selection UI because they refuse to use
extensive gnome APIs and the API you are questioning is above GTK+. They
want to keep the dependencies to a minimum so it is easier for them to
support win32, qtopia, etc... The current dialog would work totally fine
for them, if they chose to use the sound events API on gnome. Using
gconf for sound events is probably the wrong way to go about things.
Though, some of the settings are stored in gconf.

> And then, in the tab "System Bell" one can choose to "Sound an aubible
> bell", well its activated here but i never heard that bell.

These should probably actually be in some other capplet. Probably the
keyboard or a11y capplets. The control center is a bit of a mess at the
moment with all of the features for keyboards and whatnot being spread
across multiple capplets. It does indeed add to the complexity and
confusion of the desktop.

> Additionally i can imagine a much better file chooser dialog for choosing a
> sound file than that standard gnome dialog. At the moment a user has to open
> the dialog with "browse", browse to audio files and choose one, then he can
> test what it sounds like. Thats way to complicated if u want to check 10
> files or more. Nautilus sound preview in icon view does the job, but drag
> and drop works only for the adress field, not for the lists element itself
> like a drap and drop should work.

The file chooser dialog itself is a separate issue. But all in all,
there is no technically better way to make it easier to browser a
multitude of files and try each one individually. Adding a "Preview" to
the dialog, so that you can listen to the sound would help though.
Please file a bug in http://bugzilla.gnome.org/ against the sound
preferences dialog requesting a preview in the file chooser.

> What if a user inserts a cd with 1000 sound files, he opens the dialog and
> browses to the sound files he likes with the file open dialog. He chooses
> the file and removes the cd - gnome should be that intelligent to copy files
> from removable medias to a temp directory if the user is not.

This is a technical issue, not one affecting the interface or workflow
of the application. I don't think it needs to be discussed any further
on this list, but it is indeed something that must be considered when
actually implementing the code.

> Gnome sound events still only work with wav files and if i choose a ogg, it
> tells me that this isnt a valid wav file, ugly thing to force users to stick
> with wav files. Wouldn't it be better to load a 200kb ogg instead of 2MB wav
> at the moment of gnome-start?

This is a technical limitation of the APIs used to play back the audio
data. ESound does not support OGG/Vorbis, MP3, or other formats
directly. Of course, events should not be limited to sounds, I think,
but that's another issue.

> anybody working in that field?

There are various patches and changes available around. I myself have
even started working on a specification for cross-desktop sound themes,
though gnome developers were claiming that we should just get rid of
sound events, and kde people were flaming because it wasn't straight
KDE. I would be glad to continue work on the theme spec at some point.
In SUSE 10, there is an updated events dialog, which only lists some of
the more critical sound events, and has a preview. It's not the best
UI but it's much better than the current upstream dialog, I think. We're
working on improving it even further, and have done usability tests on
it by having users try to disable certain sounds.

-- dobey