Hi all As you all may be aware, there are plans to deprecate bonobo et al for GNOME 3.0. One area of GNOME's accessibility technology that is affected by this deprecation is gnome-speech, which is currently used with orca. The most likely replacement of gnome-speech is speech-dispatcher, which would introduce another external dependency to the GNOME desktop environment, however speech-dispatcher has the advantage of being usable for any desktop environment, with any application, thereby moving speech services away from being a desktop-specific service. I have been assessing speech-dispatcher's current architecture, and how it works with Orca. Orca and speech-dispatcher certainly work well enough with each other to allow for day to day use, with a bit of manual configuration by the user. However, such configuration should not be needed, except in advanced use cases. In addition, there are a few improvements that could be made to make day to day use of orca with speech-dispatcher even better. I am happy to announce the first draft of a specification document I am writing, which discusses what is required for speech-dispatcher to be more tightly integrated with orca, and the various kinds of environments where orca has to be able to function. Just about all the suggested changes in this document can also be applied to other speech-dispatcher clients in the *NIX accessibility relm, including BrlTTY, yasr, and speakup, however this document focuses on the requirements for orca. You can find the first draft of this document here: http://www.themuso.id.au/speech/speech-dispatcher-orca-integration.txt. Note you will always be able to find the most current version of the document at this URL, however I will be keeping older versions of the document at a similar location, as this document is improved. Keeping old versions will allow for looking back and working out the changes that were made along the way. I'd also like to note that I have requested time over the coming 6-12 months from my employer, Canonical Ltd, to implement the suggested changes in this document. If my request is declined, then I hope to give as much of my own time as possible to do this work, however extra contributions from the community may be required to ensure we meet a good deadline to allow for testing. All work that I do on this project will be kept open, for everybody to see, scrutinize, and contribute to. My ultimate goal is to see speech-dispatcher as the standard speech service provider for Linux, and possibly *NIX, however we do have to take things one step at a time. Please feel free to forward this document to other people and/or mailing lists, so I can get input from as wide a number of people as possible, however I strongly request that we keep the discussion about this document to one list, the GNOME Accessibility development list <gnome-accessibility-devel gnome org>, since this work will be to provide orca with a new default speech backend for the future. I am also CCing the developers of speech-dispatcher, the wonderful folks from BrailCom and the Freebsoft project, as I would also like to get their input regarding my specification. We have a lot to thank these guys for, as without speech-dispatcher as it is today, there would be a lot more work required to get to where we need to be. With a bit of luck, I will be able to get these changes implemented in under 6 months, and move onto other important speech related work, such as writing proper drivers for the various proprietary speech synthesizers that are available for Linux today, and implementing a standard for all proprietary speech synthesizer developers to follow for easy installation and use of their synthesizer, however that is for another time, and another specification document. So please have a careful read, and reply to this thread on the GNOME Accessibility development list with any nitpicks you might have. I plan to update the document at the current URL approximately every week for 3 to 4 weeks, to allow for people to see the changes that get made to the document, and to comment on them, and to allow us to end up with a well documented and agreed upon specification, so I can then start work. Thank you all in advance, and lets get this done, and done right. We should only need to do such a transition once, and that is now! Luke Yelavich Ubuntu Accessibility developer and maintainer Canonical Ltd.
Attachment:
signature.asc
Description: Digital signature