Comment 1 by jteh on 2013-02-14 09:45
More questions:

1. How do we handle sub-documents (e.g. Flash inside a web document)? My thought is that you switch to document review and then move to the containing object to get to the upper document, but this might not be obvious.
2. We shouldn't allow document review outside a document, so what happens when you move the navigator object outside a document? This also impacts the first question, as the outer document might not be immediately above the inner document.

Comment 2 by halim on 2013-02-14 14:23
My thoughts on this topic:
I am not sure if this will reduce confusion.
Frequently switching modes should be avoided.

1. In my opinion some automatic switching of current modes should be implemented.
   eg: when navigate lineup/down with braille display when a window object is focused nvda should switch to flatreview automaticaly.
   This needs a braille shortcut to jump to current review / focus position.
2. Object representation should be more configurable (again braille issue). Currently my primary working mode is (display tethered to review. The reason is that in focus mode The meta object descriptions makes it hard to find the relevant part of the Information.

Maybe speech users would also find an automatic switching useful.
What do you think?

Comment 3 by aliminator (in reply to comment description) on 2013-03-01 13:29
I would also suggest a more simplified model. For example:

1. Object: Reviews just the current object. This is what we do most of the time.

Ok. Whereby the amount of information should be configurable for each device type (speech, braille) independently. This mode is implicitly the default one if element is selected.

1. Document: Flat review of the document. Currently, this is what happens when the navigator object is a browse mode or compound document.
2. Screen: Flat review of the screen using display model. Currently, this is what happens when the navigator object is a window object. This is usually done with the move to flat review command outside of a document.

When this is the case the flat review mode should be activated implicitly. A trigger for this could be pressing keys up/down on the braille device or using appropiate gestures on the keyboard.
If flat review is not available use object navigation implicitly (the user should be informed). But keys to navigate should be still the same as for screen review.

Comment 4 by jteh on 2013-03-02 12:44
Screen review is always the least accurate and reliable mode of navigation. I don't think it's appropriate for braille to magically switch to screen review when you review by line, especially because the current object could have multiple lines anyway. If a user is more comfortable with screen review, I imagine they will just stay in screen review mode most of the time.

Comment 5 by ateu on 2013-03-26 16:32
Hi

I think it would be nicer if we can obtain the object's names with flat review, like orca does.
I noticed that when in flat review, in any window, it's also possible to activate the object represented by the text, as well as using object navigation, e.g., using insert+numpad enter or insert+enter.
So if it's possible to knows, using it, which object is being reviewed, the flat review
will be so more powerful.

Is this possible?
Should I open a new ticket about?

Thanks

Comment 6 by mdcurran on 2013-06-04 04:12
Work started in branch reviewModes 1eb6c41

Comment 7 by jteh on 2013-06-26 03:00
Changes:
Milestone changed from 2013.2 to next

Comment 8 by mdcurran on 2013-06-26 05:46
Changes:
Added labels: incubating

Comment 9 by aliminator on 2013-07-02 15:10
This is great work! One can now navigate with the Braille Display through a Window easily. Very good.

What about displaying the control types for Braille when it is tethered to Review and Screen Review is activated?
It should like the representation on Screen e.g. a Checkbox gets ist role Label on the left-hand side of the string if it is there.
This should be in Screen Review only.

Comment 10 by jteh on 2013-07-03 01:44
At least for now, screen review can't do this; it only deals with text written to the screen. As I keep saying, it shouldn't be relied upon constantly. More and more modern applications are being written such that screen review won't work at all. It is only really meant for applications where other techniques don't work.

Comment 11 by Michael Curran <mick@... on 2013-07-17 04:05
In [d18bc19]:

Merge branch 'reviewModes'. Replaces flat review with object, document and screen review modes.

Fixes #2996.

Changes:
Removed labels: incubating
State: closed

Comment 12 by jteh on 2013-07-17 05:05
Changes:
Milestone changed from next to 2013.2

Comment 13 by aliminator on 2013-08-12 14:01
What about cycling the Review modes by key press; so if the Screen view is switched to and there is no next Review mode Switch to the very first one.
And for the previous one as well...
Maybe a separate script could be created for cycling through Review modes.
Would be good to have such script for Braille Displays where many keys are not available.

Comment 14 by ondrosik on 2013-08-12 14:08
this is suggested here http://community.nvda-project.org/ticket/3392