Re: [orca-list] [Fwd: Re: Proposal: Remove the emacspeak suppport]

[Dmitri Paduchikh <dpaduchikh gmail com>]

Joanmarie Diggs:

JD> From what I have heard discussed on this list, it is getting
JD> progressively more difficult to use hardware synthesizers on systems
JD> you can just "go out and buy."

Ah, those things for computer singing. But who need this cruft? I for
one sing better than any hardware synthesizer so don't need it. <smile>

[...]

JD> Lemme put it this way: If we keep it, then I am going to need lots
JD> of testing when I completely redo the presentation support in Orca
JD> because I'm very likely going to break stuff given that I am
JD> converting code I didn't write and have little-to-no practical means
JD> of testing. And if it's completely broken, it's of no more use than
JD> if it is not even there. So if the Russian Linux community wants to
JD> step forward and help me on that front, I am willing to keep it
JD> around.

I can help with code of espeechfactory.py if needed. For beginning,
would you mind applying my patch posted recently on orca-devel-list? It
would be nice to do even if you decide to remove Emacspeak support
because the patch fixes bug outside of espeechfactory.py. Somebody added
method updatePunctuationLevel to Speech Dispatcher interface but did not
provide empty implementation for it in speechserver.SpeechServer. This
broke Emacspeak support.

Actually, after some thought it appears to me that removing Emacspeak
support wouldn't probably be that harmful for its users as long as you
keep speechserver.SpeechServer interface functioning. One could then
just place modules with Emacspeak support somewhere on sys.path and load
them in his/her orca customizations script. It would be even easier if
Orca had support for system-wide customization scripts in special
directory, say, /etc/orca.d. Third party extensions could then easily
add customization snippets there in order to load and set up themselves.

-- 
Dmitri Paduchikh