Tracking.

Add accessibility keyword.  Apologies for spam.

This information has now been added to the orca specs.

Mike, can you point me to exactly where in the spec the information
is given on what to do for this feature request please? I can't find it.

Thanks.

I should add that I found:

3.11.1. Functional Description and Status

Flat Review Test Plan

COMPLETE: V0.2.2. General flat review is working well.

INCOMPLETE: [OWNER: WDW] no automatic reading of dialogs from current position or from top left. SHOULD DELIVER FOR V1.1.

INCOMPLETE: no audio cues when navigating across line boundaries. SHOULD DELIVER FOR V1.1.

----

Hopefully that isn't it, and I've just missed it somewhere else.

All we really want to do here is the following:
Begin reading from the top of the dialog.  Simply read each object in order one after another.  
Probley what is needed is to use flat review and read by zone.  The only tricky part is: if a piece of static text takes more than one line all lines of the text should be read before reading the next object.  

Will and I discussed this today. Here are my notes:

We will need to adjust the sayAll routine in default.py 
(around line 1567) to do something like:

    if self.isTextArea(orca_state.locusOfFocus):
        ...existing code...
    else:
        ...new code...

where ...new code... is going to be a new method that
looks something like:

...
        context = self.getFlatReviewContext()

        context.goBegin()
        moved = True
        while moved:
            moved = context.goNext(flat_review.Context.ZONE,
                                   flat_review.Context.WRAP_LINE)

            [wordString, x, y, width, height] = \
                     context.getCurrent(flat_review.Context.ZONE)

            ...speak/braille... wordString
...

Note that this doesn't handle multi-line text fields. We can work out
how to do that with the second revision of the patch.

Created attachment 101325 [details] [review]
Revision #1

I've implemented the first version of the approach Will and I discussed
(no attempt to handle multi-line text fields).

But even this doesn't seem sufficient to handle simple dialogs. For example,
doing a "say all" on the Orca main window yields just:

BRAILLE LINE:  'Quit label Help '
     VISIBLE:  'Quit label Help ', cursor=1
SPEECH OUTPUT: 'Quit'
SPEECH OUTPUT: 'label'
SPEECH OUTPUT: 'Help'

and for the gedit window:
BRAILLE LINE:  'Edit View Search Tools Documents Help New Open not pressed Open a recently used file Save panel Print... panel Undo Redo panel Cut Copy Paste panel Find Replace *Unsaved Document 1  label   Ln 1, Col 1   Ln 1, Col 1   INS   INS '
     VISIBLE:  'Edit View Search Tools Documents', cursor=1
SPEECH OUTPUT: 'Edit'
SPEECH OUTPUT: 'View'
SPEECH OUTPUT: 'Search'
SPEECH OUTPUT: 'Tools'
SPEECH OUTPUT: 'Documents'
SPEECH OUTPUT: 'Help'
SPEECH OUTPUT: 'New'
SPEECH OUTPUT: 'Open'
SPEECH OUTPUT: 'not pressed'
SPEECH OUTPUT: 'Open a recently used file'
SPEECH OUTPUT: 'Save' 
SPEECH OUTPUT: 'panel'
SPEECH OUTPUT: 'Print...'
SPEECH OUTPUT: 'panel'
SPEECH OUTPUT: 'Undo'
SPEECH OUTPUT: 'Redo'
SPEECH OUTPUT: 'panel'
SPEECH OUTPUT: 'Cut' 
SPEECH OUTPUT: 'Copy'
SPEECH OUTPUT: 'Paste'
SPEECH OUTPUT: 'panel'
SPEECH OUTPUT: 'Find'
SPEECH OUTPUT: 'Replace'
SPEECH OUTPUT: '*Unsaved Document 1'
SPEECH OUTPUT: ''
SPEECH OUTPUT: 'label'
SPEECH OUTPUT: '  Ln 1, Col 1'
SPEECH OUTPUT: '  Ln 1, Col 1'
SPEECH OUTPUT: '  INS'
SPEECH OUTPUT: '  INS'

Note that it's totally missed the "File" menu bar entry, and the two
"labels" in the status bar have been repeated.

Maybe I'm being naïve, but this would suggest that our flat review
architecture is broken.

(In reply to comment #8)
> Created an attachment (id=101325) [edit]
> Maybe I'm being naïve, but this would suggest that our flat review
> architecture is broken.

It might be.  What happens when you try to use the flat review keybindings to review the same stuff?

Works just fine.

Created attachment 101326 [details] [review]
Revision #2

My previous logic was bad. It was missing the first item because
I was doing the context.goBegin() then ignoring it. 

This still left the repetition of the two items in the gedit
status bar, but looking at them in accerciser, they are both
of the form:

status bar: "Ln 1, Col 1"
  panel:
    label:  "Ln 1, Col 1"

so the code is (simplistically) doing the right thing.

> This still left the repetition of the two items in the gedit
> status bar, but looking at them in accerciser, they are both
> of the form:
> 
> status bar: "Ln 1, Col 1"
>   panel:
>     label:  "Ln 1, Col 1"
> 
> so the code is (simplistically) doing the right thing.

This looks like a gedit statusbar problem.  :-(  If the label is exposed and contains text identical to the status bar is showing, then I don't think the status bar should expose the accessible text.  What do you think, Rich?

Overall, I think this looks good and should be committed if Mike can clarify that we don't want to move focus ever (even when we interrupt speech).  That is the spec says "In a dialog orca should not attempt to move the focus durring a sayall."  So, that's during a sayall, but what happens when the say all completes or is interrupted?  Do we attempt to adjust focus or just do nothing?

> This looks like a gedit statusbar problem.  :-(  If the label is exposed and
> contains text identical to the status bar is showing, then I don't think the
> status bar should expose the accessible text.  What do you think, Rich?

I don't know whether it's a gedit bug or not.

ORCA_MODIFIER-Enter "double-clicked" does the right thing and only
speaks it once (although it does say "lane 1 colonel 1"). 

But that uses:

text = self._getObjName(self._statusBar)

so it's going through a totally different code path and taking an
entirely different approach.

Hmm...OK.  Well, I suppose we could work around in the flat review code so it will not dive into children of status bars if the status bar has non-empty text.  I just opened bug 506874 for this.

We still need to hear from Mike on what to do when a Say All of a dialog completes or is interrupted, though.  I'm guessing he doesn't intend for focus to change in those cases and your patch is fine as is.  But, I just want confirmation from him.

> We still need to hear from Mike on what to do when a Say All of a dialog
> completes or is interrupted, though.  I'm guessing he doesn't intend for focus
> to change in those cases and your patch is fine as is.  But, I just want
> confirmation from him.
>
This is correct.  I don't want this feature to impact focus in any way.   

Patch committed. Moving to "[pending]" state.

This one needs to be re-speced.  I'm putting my name back on it until I finish that. 

After more thought and discussion on this one we have decided to do the following: 
A single press of the WhereAmI key should revert back to the origional functionality where a document with a caret is read and the caret is moved.  This also applies to the orca caret in web documents.  
A double-press of the WhereAmI key will read the window with focus in logical order from top to bottom.  If a multiline control is encountered it will be read entirely before moving on to the next control.  This should no longer be restricted to just dialog boxes.  When the double-press is used the focus should never be moved.

Mike,

> A single press of the WhereAmI key should revert back to the origional
> functionality where a document with a caret is read and the caret is moved. 
> This also applies to the orca caret in web documents.  
> A double-press of the WhereAmI key will read the window with focus in logical
> order from top to bottom.  If a multiline control is encountered it will be
> read entirely before moving on to the next control.  This should no longer be
> restricted to just dialog boxes.  When the double-press is used the focus
> should never be moved.

I presume you mean "SayAll" wherever you wrote "WhereAmI" ?

(In reply to comment #19)
> Mike,
> 
> > A single press of the WhereAmI key should revert back to the origional
> > functionality where a document with a caret is read and the caret is moved. 
> > This also applies to the orca caret in web documents.  
> > A double-press of the WhereAmI key will read the window with focus in logical
> > order from top to bottom.  If a multiline control is encountered it will be
> > read entirely before moving on to the next control.  This should no longer be
> > restricted to just dialog boxes.  When the double-press is used the focus
> > should never be moved.
> 
> I presume you mean "SayAll" wherever you wrote "WhereAmI" ?
Oops sorry about that.  I guess I should have more espresso before commenting on bugs.  (smile) 
> 

Created attachment 102146 [details] [review]
Revision #3

Patch to implemented the new suggested approach.
Not committed. Please test.

Created attachment 102159 [details] [review]
Revision #4

As Will points out, "say all" should just be speaking not
brailling. Revised version to do that, which also hopefully
takes care of Mike's concern (via phone) that "the braille
display was pointing to the first widget after it had completed".

Patch committed.

Putting the bug back in "[pending]" state.

This now works great.  thanks much 

Closing as FIXED. Thanks.