• FAIL: Translation comments check. Translation comments missing or unexpectedly included. See build log for more information.
• PASS: Unit tests.
• PASS: Lint check.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/ns79jteqrtc7dgo8/artifacts/output/nvda_snapshot_pr15064-28515,dd426737.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.8,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 23.6,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 21.7,
  FINISH_END 0.2

See test results for failed build of commit dd426737d1

@LeonarddeR focusing objects should be possible in all modes:

• why user should change review mode if he/she wants to focus objects; he/she can navigate objects also in other modes so why he/she could not focus them
• if review is screen there seems to have some issues (or at least it seems to work differently) showing braille when tethered to review

Could you implement gesture also so that display manufacturers/users could define key combination if they want?

I have not tested this build or reviewed code but suppose that it works as described.

@LeonarddeR focusing objects should be possible in all modes:

I have not tested this build or reviewed code but suppose that it works as described.

Probably better test this before deciding on whether we want to do something special with focusing. Note that changing the system caret already means an implicit focus of the object in many cases.

Could you implement gesture also so that display manufacturers/users could define key combination if they want?

Yes, there is a script available for this.

@LeonarddeR focusing objects should be possible in all modes:

I have not tested this build or reviewed code but suppose that it works as described.

Probably better test this before deciding on whether we want to do something special with focusing. Note that changing the system caret already means an implicit focus of the object in many cases.

Many situations screen review is quite useless because braille shows nothing - try for example in notepad or write comment to this discussion with browser. It means that user should first change review to screen then focus object and then change review back for example to object. Why should he/she take these extra steps if he/she anyway wants to focus objects using routing buttons. He/she can try to focus that object anyway with other gesture, so what is advantage if user has to use other gesture to perform task he/she wants to do. And as you wrote focus is set implicitly anyway in many cases. This sounds quite confusing. I think better is to try to change focus if needed and to report to user if it fails. Because review cursor - I suppose - is moved anyway user may think that also focus/caret was moved. If braille is tethered to review braille shows review cursor all the time (if cursor is shown) so user cannot conclude that focus/caret was moved as well.

I hope you would change focusing behavior.

I set review to screen and tried navigate from other application (command prompt/terminal) to notepad and activat notepad with routing button. There was error in log and focus was not in notepad:

Input: br(albatross):routing
DEBUGWARNING - displayModel.DisplayModelTextInfo.get__storyFieldsAndRects (13:14:10.387) - MainThread (12284):
AppModule does not have a binding handle
ERROR - scriptHandler.executeScript (13:14:10.387) - MainThread (12284):
error executing script: <bound method GlobalCommands.script_braille_routeTo of <globalCommands.GlobalCommands object at 0x05F8BDD0>> with gesture 'routing'
Traceback (most recent call last):
File "scriptHandler.pyc", line 295, in executeScript
File "globalCommands.pyc", line 3523, in script_braille_routeTo
File "braille.pyc", line 2327, in routeTo
File "braille.pyc", line 1748, in routeTo
File "braille.pyc", line 1427, in routeTo
File "braille.pyc", line 1363, in routeTo
File "textInfos_init.pyc", line 643, in activate
File "baseObject.pyc", line 41, in get
File "textInfos\offsets.pyc", line 513, in _get_pointAtStart
File "displayModel.pyc", line 482, in _getBoundingRectFromOffset
LookupError

Could you implement gesture also so that display manufacturers/users could define key combination if they want?

Yes, there is a script available for this.

Fine.

@LeonarddeR focusing objects should be possible in all modes:

I have not tested this build or reviewed code but suppose that it works as described.

Probably better test this before deciding on whether we want to do something special with focusing. Note that changing the system caret already means an implicit focus of the object in many cases.

I think better is to try to change focus if needed and to report to user if it fails.

I hope you would change focusing behavior.

I'm not convinced honestly. Could you please provide some concrete reproducible steps to prove your point?

I set review to screen and tried navigate from other application (command prompt/terminal) to notepad and activat notepad with routing button. There was error in log and focus was not in notepad:

Input: br(albatross):routing DEBUGWARNING - displayModel.DisplayModelTextInfo.get__storyFieldsAndRects (13:14:10.387) - MainThread (12284): AppModule does not have a binding handle ERROR - scriptHandler.executeScript (13:14:10.387) - MainThread (12284): error executing script: <bound method GlobalCommands.script_braille_routeTo of <globalCommands.GlobalCommands object at 0x05F8BDD0>> with gesture 'routing' Traceback (most recent call last): File "scriptHandler.pyc", line 295, in executeScript File "globalCommands.pyc", line 3523, in script_braille_routeTo File "braille.pyc", line 2327, in routeTo File "braille.pyc", line 1748, in routeTo File "braille.pyc", line 1427, in routeTo File "braille.pyc", line 1363, in routeTo File "textInfos__init_.pyc", line 643, in activate File "baseObject.pyc", line 41, in get File "textInfos\offsets.pyc", line 513, in _get_pointAtStart File "displayModel.pyc", line 482, in _getBoundingRectFromOffset LookupError

That error looks pretty unrelated, it seems to have been caused by the second routing key press.

I think better is to try to change focus if needed and to report to user if it fails.
I hope you would change focusing behavior.

I'm not convinced honestly. Could you please provide some concrete reproducible steps to prove your point?

Steps to focus object:

• change review to screen (which you likely do not use normally); likely your display is showing empty now
• navigate to object (with speech because braille likely shows nothing appropriate)
• press routing button (if object is edit field you likely press wrong button because braille shows nothing)
• change back to other review (review to screen for example)
• correct cursor position because it was likely wrong

I set review to screen and tried navigate from other application (command prompt/terminal) to notepad and activat notepad with routing button. There was error in log and focus was not in notepad:

That error looks pretty unrelated, it seems to have been caused by the second routing key press.

This appears with first press when most left routing button is pressed. I cannot get focus moved from command prompt to notepad.

Based on above comment, it is really not clear to me why something should change here. Screen review only works in Win32 and legacy applications and as you say, you normally wouldn't use it unless you have a particularly good reason for it. Furthermore, focusing is already implemented for screen review as screen review doesn't offer a real caret.

I do not know what disadvantages to possibility to focus objects would have. I think it would be nice additional possibility.

Compared with #15044 routing buttons work differently in browse mode. In #15044 routing buttons work as in braille would be tethered to focus although braille is tethered to review. This is handy when for example user wants to select and copy some text to clipboard with standard select and copy. As user I would not like to change tether to or use review mark and copy commands in thiskind of situation. I suppose #15044 works like Jaws in this situation.

I do not know what disadvantages to possibility to focus objects would have. I think it would be nice additional possibility.

Well, I'm viewing it from the other side, if there is no clear advantage in focusing, I see no reason why we should focus.

Compared with #15044 routing buttons work differently in browse mode. In #15044 routing buttons work as in braille would be tethered to focus although braille is tethered to review. This is handy when for example user wants to select and copy some text to clipboard with standard select and copy. As user I would not like to change tether to or use review mark and copy commands in thiskind of situation. I suppose #15044 works like Jaws in this situation.

Could you please elaborate? What does #15044 do in browse mode this pr doesn't?

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/olf3obm5gvhf9fcv/artifacts/output/nvda_snapshot_pr15064-28517,d84699e8.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.9,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 24.3,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 19.1,
  FINISH_END 0.1

See test results for failed build of commit d84699e88a

I do not know what disadvantages to possibility to focus objects would have. I think it would be nice additional possibility.

Well, I'm viewing it from the other side, if there is no clear advantage in focusing, I see no reason why we should focus.

Advantage is that if you are doing object navigation then you can simple press routing button on object to focus it - no additional steps needed. Albatross has object navigation gestures so it would be fine if one could set focus with routing button, and as said implicitly focus is set many times.

Compared with #15044 routing buttons work differently in browse mode. In #15044 routing buttons work as in braille would be tethered to focus although braille is tethered to review. This is handy when for example user wants to select and copy some text to clipboard with standard select and copy. As user I would not like to change tether to or use review mark and copy commands in thiskind of situation. I suppose #15044 works like Jaws in this situation.

Could you please elaborate? What does #15044 do in browse mode this pr doesn't?

• tether braille to review
• set Move system caret when Routing review cursor to always
• open some page in browser
• make sure browse mode is active
• scroll with your display right/left/up/down keys somewhere from your current location
• press NVDA+L and then press shift+NVDA+. different lines should be reported
• then press routing button
• give above line reporting commands; with route review cursor and system caret #15044 both gestures now reports same line what you can also read from braille line at the moment

Consider you pressed routing button because you want start text selection from that point. With #15044 for example shift+right arrow selects character where you pressed routing button, shift+end would select current line to the end etc. This implementation starts selection from the position you were before scrolling with left/right/up/down. If you however are about to select text from the position where you are now (after scrollng with left/right/up/down) you should enter at least one extra gesture. Likely user has used to think that in browse mode after routing button press text selection with standard selection commands (shift+something) is possible.

Although #15044 affects on routing button press results in browse mode when braille is tethered to review (and route review cursor along with system caret is enabled) I suppose most of users expect that in browse mode and they do not want change tethering to get "usual behavior" when using browse mode. I suppose that user who wants move system caret when routing review cursor do not want lose current browse mode behavior and that he/she does not want to change tether back and forth. I do not know if profiles were working solution. How many profiles user would need to cover all applications where browse mode is needed, and what if same application have editor (in word one can use both browse and focus mode for example).

This is indeed a real issue I need to investigate. The problem is actually quite simple, browse mode uses a CursorManagerRegion whereas the review cursor uses a ReviewTextInfoRegion. Both inherit from TextInfoRegion but the cursor manager logic in CursorManagerRegion is actually pretty important.

I'm writing this from an ordinary user's point of view.

I downloaded and installed "nvda_snapshot_pr15064-28517,d84699e8.exe". Braille is tethered to Review and Move system caret when routing Review cursor is set to Always.

When I navigate to an object using my Braillex EL 80c Braille display, I noticed the same problem @burmancomp has mentioned. I went to command prompt, started object navigation and found (for Example) OmniPage 18. I pressed a touc cursor key on letter O but nothing happened. I then pressed once shift + NVDA + Numpad Minus. After that I again pressed the TC key on letter O (OmniPage). Now OmniPage started. I needed an extra step to get OmniPage started. It would be easier and more practical if I could have started the program at the single TC key press. I think that if an user could do different task by using object navigation and use a single key press of a touch cursor key to get things done would be a significant improvement to NVDA and make things easyer, faster and more efficient.

I also tested copying text from Web pages. When I read a couple of lines text, pressed a touc kursor key and then pressed Shift + End in orde to get the line (that I just read from my Braille display) selected – so I could copy it to clipboard – it copied the line from the point where I was before I started reading the text. I think it should be possible to use the Review cursor and Touc Cursor keys to mark the position, from which an user can copy text to clipboard by one way or another (Shift + End, Ctrl + Shift + End etc).

It doesn't sound a good idea that when an user reads lines after lines using her/his Braille display, she/he would have to go back to the position from which she/he began to read, when the original purpose is to copy the last line of text that she/he just read using her/his Braille display. "Just press a key and copy" sound better.

As to focusing objects with routing buttons always when it is possible, in addition to @irrah68 wrote, @LeonarddeR what do you think if it would help blind deaf users. Because they are more dependent on braille output their hands are more often on braille line. Could it have positive effect on their user experience when there would be less need to move hands back and forth between keyboard and braille line?

I am sure that next version will not suffer from browse mode problem, thank you.

* tether braille to review

* set Move system caret when Routing review cursor to always

* open some page in browser

* make sure browse mode is active

* scroll with your display right/left/up/down keys somewhere from your current location

* press NVDA+L and then press shift+NVDA+. different lines should be reported

* then press routing button

Pretty sure the last commit fixes this one.

Pretty sure the last commit fixes this one.

Yes, excellent.

Just one fix left.

To make sure we understand each other, which one is left?

Focusing objects with routing buttons when possible as @irrah68 has commented.

I think I'm convinced now.

I think I'm convinced now.

Thank you very much @LeonarddeR

I can now close #15044 because it is not needed anymore.

I think it should be done now. I probably need to improve the documentation a bit.

I'm about to test in the morning. @irrah68 will surely test as well. Thank you again.

Thank you very much. This is a significant improvement in NVDA's Braille support.

Object navigation seems to work very well now.

I seem to have some problems when I try to copy text to the clipboard from Web pages. Perhaps you can reproduce this situation.

1. Go to https://www.nvaccess.org/ and press 2 (or h) to get to the heading that says "We believe that every Blind + Vision Impaired person Deserves the right to freely & easily access a computer!"

2. Read forward using your display's navigation keys. When you see the text saying "WE CREATE THE SOFTWARE...", press the routing button on W.

3. Press Shift+End and Ctrl+C to copy the text "WE CREATE THE SOFTWARE WHICH MAKES THAT POSSIBLE" to the clipboard.

I haven't managed to copy this text from the beginning of the selected line. But if I press a routing button at the end of the line, on letter E and then press Shift+Home Ctrl+C, I'll get the text:
WE CREATE THE SOFTWARE WHICH MAKES THAT POSSIBL
Letter E is cut off.

The problem is that I can't copy from the beginning of the line. It always copies the text which says "We believe that every Blind + Vision Impaired person Deserves the right to freely & easily access a computer!". I've tried this for many times without success.

Thank you very much. This is a significant improvement in NVDA's Braille support.

Object navigation seems to work very well now.

I seem to have some problems when I try to copy text to the clipboard from Web pages. Perhaps you can reproduce this situation.

1. Go to https://www.nvaccess.org/ and press 2 (or h) to get to the heading that says "We believe that every Blind + Vision Impaired person Deserves the right to freely & easily access a computer!"

2. Read forward using your display's navigation keys. When you see the text saying "WE CREATE THE SOFTWARE...", press the routing button on W.

3. Press Shift+End and Ctrl+C to copy the text "WE CREATE THE SOFTWARE WHICH MAKES THAT POSSIBLE" to the clipboard.

The problem is that I can't copy from the beginning of the line. It always copies the text which says "We believe that every Blind + Vision Impaired person Deserves the right to freely & easily access a computer!". I've tried this for many times without success.

The problem seems to be with most left routing button.

Does this latter problem also apply when braille is explicitly tethered to focus? If so, the bug you're describing isn't related to this pr and should be handled separately.

... But if I press a routing button at the end of the line, on letter E and then press Shift+Home Ctrl+C, I'll get the text: WE CREATE THE SOFTWARE WHICH MAKES THAT POSSIBL Letter E is cut off.

This is actually expected behavior. Shift+home selects everything before the cursor, not the character at the cursor. If you'd like to select the letter e as well, you'd have to route to the position one character after that letter e.

• PASS: Translation comments check.
• FAIL: Unit tests. See test results for more information.
• FAIL: Lint check. See test results for more information.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/airp6ak6ggye5q3f/artifacts/output/nvda_snapshot_pr15064-28601,78ab1594.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.9,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 25.2,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 22.3,
  FINISH_END 0.1

See test results for failed build of commit 78ab159440

I just added unit tests that should pretty closely mimic behavior of browse mode, and these tests pass. I must be missing something.

@LeonarddeR with nvda_snapshot_pr15064-28601,78ab1594.exe routing in browse mode ("move system caret when routing review cursor" is "always") works for me! First routing button press moves cursors if review cursor is not yet there and when it is already there it activates (depending on element). Second press activates (depending on element). I have not found any new issues.

I am unsure why this snapshot works but previous did not.

I am quite a beginner but interested in learning more so could you @LeonarddeR give some more explanation about implementation for example in "description of developer approach" paragraph.

@LeonarddeR with nvda_snapshot_pr15064-28601,78ab1594.exe routing in browse mode ("move system caret when routing review cursor" is "always") works for me! First routing button press moves cursors if review cursor is not yet there and when it is already there it activates (depending on element). Second press activates (depending on element). I have not found any new issues.

Ah that's great, so seems like the unit tests are valid after all.

I am unsure why this snapshot works but previous did not.

May be it accidentally wasn't the most recent one at time of testing.

I am quite a beginner but interested in learning more so could you @LeonarddeR give some more explanation about implementation for example in "description of developer approach" paragraph.

I'll try to do that later this week.

• PASS: Translation comments check.
• FAIL: Unit tests. See test results for more information.
• FAIL: Lint check. See test results for more information.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/2uf4fkucq09wf8hh/artifacts/output/nvda_snapshot_pr15064-28618,ce602b73.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.8,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 24.3,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 22.2,
  FINISH_END 0.1

See test results for failed build of commit ce602b7366

@LeonarddeR just another minor change in userGuide.t2t: (comment)

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/51p69dwd7eaj6lto/artifacts/output/nvda_snapshot_pr15064-28620,7d5afa03.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.9,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 24.5,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 22.0,
  FINISH_END 0.1

See test results for failed build of commit 7d5afa0325

I tried to clarify the development approach in the initial comment of the issue.

I tried to clarify the development approach in the initial comment of the issue.

Thank you. I ask if I cannot understand despite of efforts.

As a reminder: should "to focus" be replaced with "to review":

This option is shown only if "[tether braille #BrailleTether]" is set to "Automatically" or "To focus".

Thanks @burmancomp fixed that now.

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/kn566cf3b6vvnvw7/artifacts/output/nvda_snapshot_pr15064-28635,031cb5d5.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 0.8,
  INSTALL_END 0.9,
  BUILD_START 0.0,
  BUILD_END 23.1,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 21.3,
  FINISH_END 0.2

See test results for failed build of commit 031cb5d553

Thanks @burmancomp fixed that now.

I suppose @seanbudd should approve this pull request. Hopefully he would have time to review this soon. And hopefully we @LeonarddeR can also co-operate with other issues in the future.

@seanbudd thanks for your comment. I think they're all fixed now.