[orca-list] Configurable speech and braille generators (was Re: Position of state vs. label for checkboxes (was Re: progress of progress bars is not reported., is it a known thing?))

[Willie Walker <William Walker Sun COM>]

> what kind of grammer were you talking about?

Well...more of some sort of expressive string similar to what you see
with the C printf method.  My early thoughts (a couple years ago) were
along the following lines:  A generator would have a generate method
that takes a format string and an object.  For example, for speech, we
might end up with:

utterances = generator.generate(format_string, obj)

The obj would be an accessible.  The format_string would be a string
containing things such as the following:

%s = object state (depends upon object type)
%l = object label
%n = object name
%R = verbose role 
%r = abbreviated role
%m = mnemonic
%a = accelerator
%g = object sensitivity (i.e., grayed or not)

The return value would be a set of utterances, where each utterance was
a string to speak and the ACSS (e.g., voice, pitch, etc.) for how to
speak it.  I also had a notion of putting in some sort of conditional
syntax for specifying a subset to speak when the object's state changed
when it already had focus.  For example, speaking just 'checked' or
'unchecked' when you change the state of a checkbox after you've tabbed
to it.  I never really figured that out, but it was something like
surrounding the text in square brackets (e.g., '[%s]').  

So...let's look at something like generate("[%s] %n %r %m",
some_checkbox).  When you first tabbed to a checkbox, the results of a
call to 'generate' would produce a one-item list of utterances that
contained "checked red checkbox Alt+m" as the string and the checkbox
voice as the ACSS.  When you changed the state of the checkbox, you'd
just get "checked" or "unchecked" and the checkbox voice as the ACSS.

The generator would maintain a dictionary of some sort that mapped
object role names to format strings, and this dictionary would be
modifiable by user settings.  As such, the user could feel free to
change the speech in many different ways.

Doing this would have been a bit of work, though, and I never really
convinced myself it was the right way to go.  For example, instead of a
string like the above, one might just consider writing methods.  For
example, maybe the SpeechGenerator class could provide some sort of hook
to call out to the user settings to get specific methods for specific
roles.

> If you are talking about some specific terminology, then you can
> expect a lot of help from me.  although we should not go to the extent
> of emacspeak, we can surely define some good grammer and way things
> get represented.

That would be interesting!  I'd like to hear more about the emacspeak
way.  Maybe we can take this off line for a bit.

> ...bunch of other questions...

If possible, please try to keep a single message to a single topic.  It
makes it much easier to track, and it also makes the archives much
easier to search in the future.

Thanks!

Will