Re: [orca-list] Punctuation, capital letters, exchange of characters and strings, generally error in the design of Orca



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 11, 2008 at 12:27:39AM EST, Willie Walker wrote:
Until it is complete, stable, and we're sure it helps us meet the user 
requirements, I cannot make SpeechDispatcher a supported part of Orca. 
We have at least gotten to the point where we've identified the API that 
will be exposed to Orca, which is the speechd Python bindings.  With the 
exception of some things, it sees like a viable API, though I need to 
dig into it a little deeper.

Assuming the API is workable as is, do you have an estimate for the 
amount of work (cost and timeframe) needed to complete the 
implementation and provide complete support for at least eSpeak, 
Festival, Cepstral, DECtalk, and IBMTTS?  What is your support model and 
release schedule going to be once the implementation is done?  What is 
your community model going to be (e.g., can others outside Brailcom 
contribute patches/enhancements to SpeechDispatcher)?

I'd just like to make my voice heard, as an Ubuntu and Accessibility developer/integrater. I too think 
speech-dispatcher is the way of the future, but I certainly don't see a need to re-implement it, purely in 
python. Will, I think we would be better off extending the current speech-dispatcher, both saving time, and 
allowing a cross-platform/cross-desktop solution to be ready that much sooner.

KDE will likely have some form of accessibility in the future, with their own tools. I think both desktops 
should be using the *ONE* speech backend. KDE accessibility folks have already stated that they would choose 
speech-dispatcher in the event they get accessibility things going, in whatever form that may be. So I am of 
the belief that we should be doing our best towards making *ONE* speech backend the standard now, and get it 
in shape in the quickest and most efficient way possible.

I've been considering using speech-dispatcher in Ubuntu's next release, instead of GNOME-speech, as that is 
what users want. I am not going to bother with making this change, if we are only going to have to replace it 
later, with a re-implementation that seems to me, unnecessary, as the existing project/package can be 
extended. As far as my work on Ubuntu/with Canonical will allow, I am willing to help spend time helping to 
code the extra bits that are needed, dispite the fact that I don't know a lot about the speech-dispatcher 
architecture. I want to get the best tools available into users hands just as much as the next person, but if 
we are still going to be changing bits and pieces into the future, we are possibly going to put off future 
users, and developers, who come from other platforms.

Luke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH/pfrjVefwtBjIM4RAtBPAJ9FayJShwsjY7bilqxU1HNBcmqa7QCg2CWC
V5QzGuB+xG9hX5P3jjRIgdg=
=j3eo
-----END PGP SIGNATURE-----



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]