Re: [orca-list] How you can help

[hackingKK <hackingkk gmail com>]

On Wednesday 03 March 2010 08:47 AM, Joanmarie Diggs wrote:
> Hey all.
>
> Off and on over the past few weeks there have been threads on how one
> can contribute to Orca. For those of you with the time and interest who
> are not quite ready to dive into scripting, but want to eventually be
> ready to do so, I have a proposal:
>
> Pick your favorite app (e.g. Firefox, OpenOffice, whatever). Set up an
> environment in which the only variable is that app, and where you can
> have multiple versions of that app co-existing simultaneously. Then use
> the most bleeding-edge version of that app as often as you can.
>
> When something breaks, do the following:
>
> 1. Identify as precisely as possible the version/build where things
> broke. The closer you can get to an exact date and/or build the better.
>
> 2. Having found the first version/build that is broken (say, Firefox 3.6
> from 15 September), reproduce the problem while capturing a full
> debug.out. (See http://live.gnome.org/Orca/Debugging for more info.)
>
> 3. Perform the very same steps, commands etc. in the last version/build
> that is not broken (e.g. Firefox 3.6 from 14 September), also capturing
> a full debug.out.
>
> 4. Compare the two debug.outs. They should be awfully similar because
> the only thing that's different is your favorite app, and you've taken
> the time to find the exact version of that app where things changed. So
> find out what happened: Look for events that are missing. Look for new
> events. Etc.
>
>    
Might as well help to start working on a totally inaccessible app such 
as evince.

> 5. Take all of the above data along with your analysis of it and file a
> bug against the appropriate component. That might be Orca; it might be
> the app you were testing.
>
> 6. As you develop strategies for quickly pinpointing a problem, add it
> to the wiki so other community members can join in this effort.
>
>    
Very Very good stratergy indeed!

> Beyond helping the team out, I can tell you personally that once you've
> stared at enough debug.out files a lot will become clear. It does take a
> while. And you may have moments along the way where you think, "Joanie
> must be nuts, this stuff makes no sense."
Joani must be really nuts, that's why firefox accessibility has become 
usable with orca in such a short span of time. :)
I recall that a certain proprietory screen reader took more than 3 years 
for making web as accessible as orca makes it today, and all thanks to 
the hard work of Joani.

> But trust me: You'll start to
> get it, because you'll see what Orca is reacting to and how it's
> reacting to it. From there, you can start modifying the code where
> Orca's doing that reacting and see what changes as a direct result of
> your modification. This process will expose you to Python and the
> general coding style and conventions used within Orca. And once you've
> got that down, you'll be able to start fixing bugs and ultimately
> writing scripts, at which point I am *so* going on vacation.<grin>
>
> All kidding aside, the process I've described above is how I got to the
> where I'm at now. And if I can do it, you can do it.
>    

I think just a few days back wil had posted me a link from the Orca 
mailing list inself.  It was having a small script for running pyatspi 
and checking how accessibility infrastructure works in a flow.
So once we follow the debug steps given in this email and learn as 
things become clear, the next step would be looking at that script (I 
can't remember the exact link, but downloaded that script for me).
I am bennifiting from it and I am going to recommend it to a lot of 
people interested in Orca scripting.

Happy hacking.
Krishnakant.