Subject: Re: Faces audio support - comments please.

From: richb@stard (Rich Burridge)
Date: Thu, 4 Apr 1991 12:03:44 +1000

} From: John Mackin <[email-masked]>
} Date: Thu,  4 Apr 91 10:17:16 +1000
} How can I catch up with the huge backlog of stuff I need to do for you
} _and_ take part in current-time discussions on the list at the same time?
} (That's rhetorical and I am choosing the second.)

Get a boss on the other side of the planet like me. It really works. :-)

} 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.

It would be fairly simple to add this support in as well, but separate from
the individual host/user audio support. How about this? There would be an
X resource something like:

   faces.newmailAudioFile:	/usr/local/sounds/cowbell.au

If this resource is present, and audio is enabled, then the new mail sound
would be played first, followed by possibly other user specific audio files.
Also, the ability to specify the new mail audio file via the command line
option:

  -B /usr/local/sounds/cuckoo.au

} 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'll quickly add one comment here. I'd like the ~/.facerc file to be in
Xdefaults format. I'd have to add in the ability for the SunView and NeWS
versions to parse this file, but in the case of the X and XView versions,
this file would simply be merged with the other resources from various X
places in load_resources().
 
} 	Option arguments cannot be optional.

I've no problems with this. In fact, it makes my life simpler. I'll use
-A for enabling audio, and -C <command> for the alternative audio command
(-P is taken).

At a later date, I'd really like to convert the arguments to words like:

% faces -audio -printer minnow     etc...

I realise Unix is used to terse commands and arguments, but it's easier to
understand longer words (especially if all you've got is a usage message).
This is probably a religious issue, so I better be careful here. :-)

For now I'll add three things to the TODO file:

* Convert ~/.facerc to Xdefaults format. Add in support for the SunView and
  NeWS versions to be able to read this file.

* Possibly convert command line arguments to word equivalents.

* Need to add a Faces.ad application resources file to the faces distribution.

Thanks for the comments John.

---

From: richb@stard (Rich Burridge)
Date: Thu, 4 Apr 1991 17:31:03 +1000

Hugues, I apologise in advance for mailing your suggestion to the mailing list
without your permission. I hope you don't find this inappropriate.

} From [email-masked]
} Date: Thu, 04 Apr 91 09:09:55 +0200
} For audio support, we have xbiff++ with ressources such as:
} 
} xbiff*soundBindings:\
} From:.*jbanatre|/usr/site/share/sounds/oh_my_god.au,\
} From:.*leroy|/usr/site/share/sounds/ahoohoo,\
} From:.*Mailer-Daemon|/usr/site/share/sounds/sorrydave,\
} Subject:.*Restau.*|/usr/site/share/sounds/woo_woo_woo_hoo.au
} xbiff*volume:50
} 
} so instead of creating new files host/user/face.au, what about the xbiff way?

My own opinions here:

Face.au audio files take much less processing.

With the resource type info, there is yet another file (list) to search
through for every mail message. If this list is long, then there are a lot
of checks needed to determine if you should be playing a sound.

With the face.au file, one stat() is all you need.

Alternatively, the resource approach allows individual customisation per
user which is really nice, and something the face.au approach doesn't.

What do other people think? I like this idea. I'll grab a copy of xbiff++
to see if the copyright notices make the code reusable, and to see if they
have any fast techniques for processing the list to see if there is a sound
file for this user/host.