Re: Evince accessibility (was Re: [orca-list] sayAll command not working in adobe reader)

[Willie Walker <William Walker Sun COM>]

> well, if that's the case then some one from the evince development
> team could do it.
> but will it be sufficient enough?

A good implementation would be a good thing.  :-)

> secondly, since this topic has come up again, Please can some one
> provide a checklist of "to be known things " for scripting the
> following in orca?
> 1, mozilla firefox.
> 2, openoffice.org
> and
> 3, audacity?

We try to keep track of all the things that need to be done, which 
includes bugs and feature enhancement requests, in Bugzilla:

http://bugzilla.gnome.org/buglist.cgi?query=product%3Aorca

http://live.gnome.org/Orca/Bugs contains information on how we organize 
the work.

> what particular things would need understanding in all the above
> softwares?  and if I for example decide to start reading the orca
> scripts for openoffice writer and calc, what should I know in advance
> even before touching these scripts?

The docs are out of date, but available under the docs/doc-set directory 
in SVN.  The internals documentation is in two files: internals.pdf and 
internals.html.  As I mention, they are out of date (we've been too busy 
working on the long list of things everyone wants us to do), but they 
are kind of worth a read.  I hope to update them before the 2.24 release.

After that, you should become familiar with the AT-SPI -- it is Orca's 
view into the application.  For me, the best thing was to read the 
AT-SPI IDL - http://svn.gnome.org/svn/at-spi/trunk/idl/.

Also, playing around with accerciser can give you an idea of how the 
AT-SPI works.

From there, the rest is left to experimentation and hands on work.  Use 
the orca debug facility gratuitously, look at other scripts, etc.  I 
wish there was a "for this bug, write these lines of code" guide, but 
each bug and feature tends to be unique.  :-(

Hope this helps,

Will