Re: GTK & SOUND

[Paul Davis <pbd Op Net>]

>By this logic, gdk_beep() should be removed, because the speaker may
>not be operational.

No, by this logic, no program should use gdk_beep() to convey
something important. mea culpa :)

>By this logic, *ANY* feature that may not work everywhere should be totally
>ignored as an option.

An approach often taken in GTK+, and quite often mentioned on this
mailing list, yes.

>gtk shouldn't support 24-bitplane graphics.  If it's not doable in 8-bit,
>why bother?  Seems like a lot of people *like* 24-bit and 3D extensions, and
>programs are written to take advantage of them.  Are you saying that people
>shouldn't use OpenGL because not every system has one?

people shouldn't write toolkits for general use that *rely* on features
that may not exist. gtk supports 24-bitplane graphics, but it doesn't
*rely* on them.

likewise, i don't think that a program should *rely* on audio. playing
an audio clip is not carrying out an action that is easily rendered
into other forms (e.g. for deaf users). 

>There shouldn't be support for mice with more than 2 buttons, because not
>everybody has one.  Are you saying that there should be no provisions for
>binding mouse buttons 4 and 5 because not everybody has one?

no, i'm saying that a program that relies on mouse buttons 4 and 5 to
work is less useful than one that doesn't. providing a way to use
those buttons is not the same as using it. there are no doubt some
specialized programs that benefit from button 4/5 support, and almost
all GUI programs could be improved by using it. but *relying* on it to
carry out an important function is quite different.

>There shouldn't be support for alert dialog boxes, because there's no
>guarantee that the user *looked* and *comprehended* it before they
>clicked "OK".

user stupidity can never be guarded against. relying on complex
facilities that will not always work can be avoided.

>I *DID NOT* say that Gtk should support sound.  WHat I *said* was that
>large classes of programs can *benefit from sound if available*.
>
>OK, so *TOTALLY STRICTLY ANALLY-RETENTIVELY SPEAKING*, the fact that I use
>text-to-speech to tell me who my mail is from is "not critical, so why
>bother?".  Yes, I *might* be out of the office.  Yes, I *might* miss it.
>
>However, it's certainly a *NICE* feature to have - 85% of the time, I *am*
>in my office, and I *do* get the alert, and it helps me manage the time.

No doubt. Its all a question of design. I didn't want to imply that
there was never a use for sound. But if your mail program wouldn't
tell you who mail was from anyway other than "speaking" it, I think
you'd accept that it was badly designed. Why is this different than a
program that does other things *only* via a sound interface? I don't
think it is, and I worry that people will write programs that assume
that sound can be used to convey important information. That
assumption is not valid; the fact that its true often means that sound
is a useful adjunct to program function, but it should never be the
core of it. Thats all I want to get at.

--p