Re: GTK & SOUND
- From: Paul Davis <pbd Op Net>
- To: Valdis Kletnieks vt edu
- Cc: Roberto <robyegiuly libero it>, GTK Mailing-List <gtk-list gnome org>
- Subject: Re: GTK & SOUND
- Date: Thu, 03 May 2001 19:19:56 -0400
>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
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.
] [Thread Prev