From: richb@Aus.Sun.COM (Rich Burridge)
Date: Thu, 4 Apr 1991 08:07:37 +1000
I'm going to try to add audio support to faces for patch #15.
Before I do, I'd like to throw my ideas at the list, and get a
discussion going. I know that John has some ideas on this. My
perspective is also biased towards Sun gear, so my ideas might not
be as general as they should be.
I do indeed have ideas. I won't quote Rich's mail at length here;
see the referenced message. I do want to stress that I too am most
interested in hearing from people with non-Sun audio support, since
I, like Rich, have Sun hardware. (There does seem to be a pretty reasonable
de-facto standard for telephone-quality audio data, though, namely 8 bits
inverted signed x 8000 per second; happily, you can cat that at /dev/audio
on a Sparc and it works. Other systems don't support the same sound
file header format that the Sparc software does (and that some file(1)
commands recognise -- file begins with ".snd"), so we probably shouldn't
tie ourselves to that (not that anything Rich suggested meant that we
were doing so).)
Now about Rich's suggested implementation. It's much more ambitious
that what I had in mind. I was just going to add a command which would
be system()'ed instead of ringing the bell, if it was present. So, there
would just be one "There is new mail" sound, not a sound per face.
(This could also be accomplished at the protocol level, by using the Xsun
contributed audio-bell mods, but that means you get the same sound when
any application rings the bell. That's all very well, but my goal here was
a distinguished sound just for mail arrival. And of course, that assumes
not only that you are using X, but that you can hack your server; neither
assumption is true for the whole faces user community, by a wide margin.)
Unfortunately, Rich's suggested implementation does not allow what I want,
unless you are prepared to go to the overhead of a face.au symlink in
_every_ leaf directory of the tree; in most instances, to the default
sound, otherwise to the particular sound. This is quite ridiculous,
and is really the only quarrel I have with the suggestion's design.
There should be an optional resource "audioDefaultFile" or similar,
and parallel .facesrc options, command line options, etc. If the file
is specified and no .au file is found in the leaf where the face is,
then that file is played the same way a .au file in the leaf would have
been.
I also have some general comments about X resources vs property sheets vs
command line arguments vs .facesrc etc ad inf, but I will hold them for
a later message in the interests of getting this one out.
I do have one problem with the detail, as opposed to the concept, of
Rich's suggestion:
* There will be a new command line option:
-A [play command]
-A on it's own enables audio support. It's disabled by default.
-A [play command] allows the user to supply an alternative command to
obey, to "play" the audio file.
This is in contravention of the SVID. Those of you that know me either
know what's coming or are shocked, since I would never advocate that anyone
follow the SVID; but in this specific instance, its English is _so_ beautiful
that it can't be resisted, to wit:
Option arguments cannot be optional.
(SVID aside, it's bad user interface design anyway.) What that lovely
sentence means is that if you have an option, say -A, then it either
always takes a following argument, or it never takes one. If you're
using getopt or similar to parse your arguments, you must do it like this
anyway. It also means that the user doesn't have to worry about whether
there should be whitespace between the option and the argument.
So, concretely, I suggest: -A enables audio support, disabled by default;
-P <command> turns on -A and sets the play command to the one given.
I don't care what the names really are, all I care about is that `option
arguments cannot be optional'.
More later,
John.