Re: [GnomeMeeting-devel-list] Re: Sound events and GnomeMeeting

[Glynn Foster <Glynn Foster Sun COM>]

Hi,

> > Absolutely, and I wasn't suggesting that we remove the API for this, but
> > rather remove all the application specific sound events from the capplet.
> 
> I still don't think this is the right thing to do. It's basically the
> only thing in the capplet that is worth having the capplet for. It
> provides a nice interface for theming sounds, as well.

What makes you think that we need themed sounds in the desktop? The
article doesn't exactly suggest it, and in fact seems to suggest that
the M$ type jungle/space/train/... sounds are overkill.

> Again. This is just something that would never be used by much, if
> anything. You can't have one sound to notify you of 50 different
> types of alerts. That is just broken. And it has to be configurable.
> Audible awareness is very much a part of the Look and Feel of one's
> desktop. It is very similar to the Low Contrast/High Contrast/etc...
> accessibility and theming issues that are present with Widgets and
> their colors.

So have 50 different alert sounds for 50 different applications? I'd
very much like to hear Bill/Calum's thoughts on the issue.

> We do need something in the HIG to better inform people of what sounds
> to use, and when and how to use them. We don't need to add yet another
> configuration page to every single application that wants to use sound
> events, because it will just make those applications that much more
> complex. 

Yes, but most applications shouldn't need sounds. Sure, for things like
instant messaging, video conferencing, games they might be desirable,
but for most other things there is no requirement.

> I think having a cross-desktop configuration solution that
> allows theming, is the best way to take care of the problem of having
> multiple sound events and configuring them. Basically, this was my goal
> with the sound theme spec I tried to propose a while ago on xdg-list. As
> I said in my last reply to you, I would be glad to re-start that
> initiative and get it somewhere useful.

Well, whether it's cross-desktop or not, we still haven't identified
what the user requirements are, and what tasks if any are they likely to
do that involves sound theming. I'd certainly like to get those more
concrete first.

> > If they are useful, then why didn't someone complain that they weren't
> > there? certainly sounds like they're not being used all that much ;)
> 
> Because they are buggy, and it has always been easier to ignore than to
> complain about it and get it fixed. 

Hrm, I think you're confusing 'buggy' with 'arse'. One of our CEO's has
specifically asked for a new login sound because the current one really
sucks.

> It's a difficult problem to solve,
> and speaking from a user's perspective, very hard to communicate what
> one thinks is wrong, to members of the developer community. If I had the
> time, I could install every gtk+/gnome application that exists and make
> a list of all the applications that use sound events, but I don't have
> that time. 

Currently I see the following in my sound capplet -
	
	o Gnect, Gnibbles, Gataxx, Iagno, Robots
	o gnome-meeting
	o battstat
	o mailcheck
	o gnome-session
	o user interface clicks, toggles, ...

and Gaim, which seems not to use the gnome-sound stuff. This doesn't
seem like a huge proportion of GNOME applications.

> User's are adverse to using the sound events, because there
> are annoying bugs that are non-trivial to fix. For example, open a large
> document in AbiWord, and change the scaling of the document. If that
> doesn't cause the toggle buttons in the toolbar to activate enough times
> to make you want to turn them off, then start at the top of the
> document, and hold down or page down for a while and listen to the sweet
> harmony of the button clicking sounds. Yes. This is why people turn the
> sound events off.

Which kind of suggests that they didn't need the sound in the first
place. If they missed it they would complain.

> Throwing a new multimedia framework at an old problem won't solve it. In
> fact, just shoving gstreamer under the sound events API right now, will
> probably actually cause more problems. 

No, I was suggesting that we don't need the current sound events API,
and that people should just use gstreamer directly - it seems to work
well for monkeybubble and others..

> http://primates.ximian.com/~dobey/screenshots/multimedia-properties-sound.png
> 
> This is a mockup of the sounds page of a new multimedia capplet for
> GNOME that I made back when I made the initial draft of my sound theme
> specification. It was basically a straight rip of the Windows sound
> capplet in ME. An initial draft if you will. I will rethink parts of it
> and make a better mockup soon, but it seems like something we definately
> need. Maybe it would be a good idea to put up more screen shots of what
> other desktops like KDE, BeOS, QNX, and XFCE do.

Certainly seems a little too confusing currently. I don't really see the
need for 'Play' or 'Save As'. Perhaps s/Browse/Install seems more
consistant with other capplets. Think we could probably remove the Name
and Theme combo boxes too, with a clever enough design.

Glynn