* There will be a default command for playing audio files.
* There will be an additional two entries in the Makefile.dist file for
specifying whether the program is capable of supporting audio, and an
option audio play command (to override the default one):
#AUDIO_SUPPORT = -DAUDIO_SUPPORT
#AUDIO_CMD = -DAUDIO_CMD=\"/usr/local/bin/play\"
* 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.
* There will be two new X resources:
faces.audioSupport: true [default is false].
faces.audioCmd: /usr/local/bin/play
* The XView property sheet will have another check box:
[ ] Audio support
* Whether an audio file should be played is determined by the presence of a
face.au file in the host/user directory. I suspect that due to the size of
most audio files, these will really be symbolic links to a large audio
file directory somewhere.
* Because faces currently checks so many different directory and name
combinations, I suggest that it should only look for the face.au file
when an equivalent face.xbm/48x48x1/sun.icon/face.ps file has already
been found. In other words, there shouldn't be host/user directories
with just a face.au file in them, because with this suggested lookup
technique, they simply wouldn't be found.
I suspect this point will be a hot topic for discussion. I'm flexible,
but faces is really slow at the moment on large mail files.
* When a face.au file has been found for a host/user (could be misc./unknown)
then if audio support is enabled, the system() library call is used to
play the sound. I considered forking a process, but it's possible that
there could be a lot of host/user's that will have audio files associated
with them, and you could end up with a couple of dozen sub-processes going.
Combine that with the fact that only one process can have the Sun audio
port open at any one time, I really wasn't left with too much choice.
So there are my suggestions. This is surprisingly simple to implement, and
hopefully would be a stiff competitor for those new xbiff++ programs that
are starting to emerge on the net.
Comments please.