Re: [orca-list] helping making eclipse debug more accessible with orca

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hey JosÃ.

> I wish the line containing the breakpoint were read when the breakpoint 
> was reached, but orca stays mute.
> I think the problem could be solved if the eclipse would send a 
> object:state-changed:focused event.

I'm not so sure that's the answer. Take a look at this part from your
output:

> vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv
> OBJECT EVENT: object:text-caret-moved                  detail=(2190,0,None)
>      app.name='Eclipse' name='None' role='text' state='editable enabled 
> focusable focused multi line sensitive showing visible' relations=''

[I've deleted the bulk of braille generator stuff]

> default.py:isReadOnlyTextArea=False for app.name='Eclipse' name='None' 
> role='text' state='editable enabled focusable focused multi line 
> sensitive showing visible' relations=''
> readOnly=[]
> nodeLevel=[]
> generate braille results:
>    Text: '        boolean restart = true; $l', 0
> BRAILLE LINE:  '        boolean restart = true; $l'
>       VISIBLE:  '        boolean restart = true; $l', cursor=1
> ^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^

Assuming that the line containing the breakpoint is the one with:

        boolean restart = true;

Then I see that we are getting the correct caret-moved event and that
the object already has STATE_FOCUSED. So if we were to get a new event
-- the one you are suggesting Eclipse add -- that tells us that the
focused thing that we already know is the locusOfFocus is focused, we'll
ignore that event. And if for some reason we didn't ignore that event,
that would be a bug in Orca.

I also see that we're correctly updating the braille display to reflect
the new location. And finally, I see that, as you indicated, Orca fails
to speak the new location.

This is another example of where custom scripts come in handy. There is
no custom script in Orca for Eclipse. In part, that's the result of the
"tiny team, not enough time" situation. And, to the credit of the
Eclipse developers, in part it just hasn't been necessary. The Eclipse
team has clearly gone out of their way to make Eclipse JustWork(tm) with
screen readers, which is awesome.

Getting back to the breakpoint behavior: The default script looks to see
what key was pressed and from that determines whether or not to speak
something and, if so, what to speak. If you press Right or Left we
should speak a character -- unless you held down Control as well, in
which case we should speak a word.  If instead you pressed Up or Down we
should instead speak a line. Etc., Etc. From your output, it looks like
you pressed F11 last. That's not in the default script. Nor should it
be.

Custom scripts are designed to handle custom situations. Most apps don't
have breakpoints you can set. Therefore, the speaking of the line to
which the caret moved as the result of a breakpoint having been reached
is a custom situation which can and should be handled in a custom
script.

If you are willing to give implementing this a shot, I'd be more than
happy to help with any questions you have. If you're game, please file
an RFE.

Thanks and take care.
--joanie