Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update braille independently on caret #15163

Merged
merged 25 commits into from Aug 29, 2023

Conversation

burmancomp
Copy link
Contributor

@burmancomp burmancomp commented Jul 18, 2023

Link to issue number:

Fixes #15115

Summary of the issue:

This extends pull request #15134 and includes pull request #15156. Collaborated with @LeonarddeR.

Description of user facing changes

Braille line is updated in terminal window when there is text change.

In addition braille line is updated in any application when:

  • braille cursor is turned on or off with gesture
  • if there is selected text in edit control or document, changing "show selection" state with gesture updates braille line when otherwise supported

Description of development approach

Terminal window updates are handled with:

  • NVDAObjects.behaviors.Terminal.event_textChange and
  • event_UIA_notification in winConsoleUIA._NotificationsBasedWinTerminalUIA.

Objects are passed to BrailleHandler.handleUpdate function.

When braille show selection state is changed with gesture, BrailleHandler.initialDisplay function is executed.

When braille cursor is toggled with gesture, BrailleHandler._updateDisplay function is executed.

Testing strategy:

Tested with Albatross 80 and little with Optelec Alva BC680.

Known issues with pull request:

none known

Change log entries:

New features
Changes

  • When the text in a terminal changes without updating the caret, the text on a braille display will now properly update when positioned on a changed line. This includes situations where braille is tethered to review.

Bug fixes

  • The braille cursor and selection indicators will now always be updated correctly after showing or hiding respective indicators with a gesture.

For Developers

  • braille.handler.handleUpdate and braille.handler.handleReviewMove have been changed in order not to update instantly. Before this change, when either of these methods was called very often, this would drain many resources. These methods now queue an update at the end of every core cycle instead. They should also be thread safe, making it possible to call them from background threads.

Deprecations:

  • braille.BrailleHandler.handlePendingCaretUpdate is now deprecated with no public replacement.

Code Review Checklist:

  • Pull Request description:
    • description is up to date
    • change log entries
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • API is compatible with existing add-ons.
  • Documentation:
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • Security precautions taken.

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit b95da15196

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit 621db0d2a3

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit d33cb7f891

@AppVeyorBot
Copy link

See test results for failed build of commit 2165a40281

@AppVeyorBot
Copy link

See test results for failed build of commit 513924ae0f

@AppVeyorBot
Copy link

See test results for failed build of commit 4c50ada91e

@AppVeyorBot
Copy link

See test results for failed build of commit cca30e202a

@AppVeyorBot
Copy link

See test results for failed build of commit db74e0cddd

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit 02c14674f5

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit c8f952a425

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit a6183d1bc7

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit b748d3f826

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit 0c530a1c6e

@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit 1c7b399611

@burmancomp burmancomp marked this pull request as ready for review July 26, 2023 09:07
@burmancomp burmancomp requested a review from a team as a code owner July 26, 2023 09:07
@burmancomp burmancomp requested a review from seanbudd July 26, 2023 09:07
@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit ef8163f39d

@burmancomp burmancomp force-pushed the updateBrailleIndependentlyOnCaret branch from 84be35d to 8c947d9 Compare July 26, 2023 10:28
@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Jul 26, 2023

While I like this pr as a proof of concept, I see several reasons why this doesn't fit for NVDA Core, as it is merely a workaround and obfuscator of other bugs that should have our attention instead:

  1. Most notably, it has a polling/timer based approach instead of event driven.
  2. A timer on the main thread like this may severely impact NVDA's performance in objects that are slow to update, such as Excel, some more complex UIA implementations, etc. A timer on another thread will probably result in issues with thread safety.

Again, I really like your investment in this, but I'd rather see #15134 being merged first and then have smaller follow ups like #15156, but even the latter is already to broad in scope and I decided to close it. The braille subsystem of NVDA is pretty complex and hard to oversee and it is very, very easy to break things

@LeonarddeR LeonarddeR added the blocked/needs-product-decision A product decision needs to be made. Decisions about NVDA UX or supported use-cases. label Jul 26, 2023
@AppVeyorBot
Copy link

  • PASS: Translation comments check.
  • Build execution time has reached the maximum allowed time for your plan (60 minutes).

See test results for failed build of commit 19b4701ac9

@burmancomp
Copy link
Contributor Author

Thank you @LeonarddeR for your comments.

1. Most notably, it has a polling/timer based approach instead of event driven.

What kind of event driven approach you are thinking?

2. A timer on the main thread like this may severely impact NVDA's performance in objects that are slow to update, such as Excel, some more complex UIA implementations, etc. A timer on another thread will probably result in issues with thread safety.

Currently it is run once in 0.5 seconds, and it tries to avoid redundant updates. There is also _cursorBlinkTimer polling in 0.25 seconds cycles as default in main thread. Is an additional timer a problem or its polling cycle or what it is doing?

I tried also with timer in its own thread but in browser there is _ctypes.COMError when switching from browse mode to focus mode.

This pull request should only do something with timer when:

  • current object is terminal window (and before update it is checked that braille content has been changed)
  • state of show selection is changed
  • braille cursor is toggled.

I suppose that most of time only above checks are done, and this is once in 0.5 seconds.

Again, I really like your investment in this, but I'd rather see #15134 being merged first and then have smaller follow ups like #15156, but even the latter is already to broad in scope and I decided to close it. The braille subsystem of NVDA is pretty complex and hard to oversee and it is very, very easy to break things

There may be problems but I suppose they are met in testing or maybe they can shown with calculations.

Could you tell whatkind of tests should be done?

It is not important that this implementation would be merged but these things are important.

When and if for example font attributes are presented in braille switching that state on and off is important. What I try to say is that these things should be solved anyway so why not earlier than later?

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Jul 26, 2023

What kind of event driven approach you are thinking?

There is already the textChange event fired on terminal objects when the text changes. That event should be fired when anything changes in the text, including check boxes in terminals. If not, that's a bug that needs to be looked into first.
Currently, no braille updates are performed in event_textChange, so that would be a good starting point.

@burmancomp burmancomp force-pushed the updateBrailleIndependentlyOnCaret branch from b3ef673 to 6a5b4d7 Compare July 27, 2023 20:48
@LeonarddeR
Copy link
Collaborator

@burmancomp could you please add the following to tests/unit/__init__py, below braille.filter_displaySize.register(getFakeCellCount)?

_original_handleReviewMove = braille.handler.handleReviewMove


def _patched_handleReviewMove(shouldAutoTether=True):
	"""
	For braille unit tests that rely on updating the review cursor, ensure that we simulate a core cycle
	by executing BrailleHandler._handlePendingUpdate after Braillehandler.handleReviewMove
	"""
	_original_handleReviewMove(shouldAutoTether)
	braille.handler._handlePendingUpdate()


braille.handler.handleReviewMove = _patched_handleReviewMove

@AppVeyorBot
Copy link

See test results for failed build of commit 7d68bd7314

@AppVeyorBot
Copy link

See test results for failed build of commit 860a4c4d5e

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Aug 24, 2023

I'd like to suggest the following changelog entries:

Changes:

Bug fixes

  • The braille cursor and selection indicators will now always be updated correctly after showing or hiding respective indicators with a gesture.

Changes for developers

  • BrailleHandler.handleUpdate and BrailleHandler.handleReviewMove have been changed in order not to update instantly. Before this change, when either of these methods was called very often, this would drain many resources. These methods now queue an update at the end of every core cycle instead, behaving very much the same as BrailleHandler.handleCaretMove. They should also be thread safe, making it possible to call them from background threads.

Deprecations:

  • braille.BrailleHandler.handlePendingCaretUpdate is now deprecated with no public replacement.

@AppVeyorBot
Copy link

See test results for failed build of commit 9de47c2e25

@burmancomp
Copy link
Contributor Author

Changes:

* When the text in a terminal changes and braille is tethered to review, the text on a braille display will now properly update if the review cursor is positioned on a changed line. ([braille: update display when tethered to review and review cursor does not follow caret #15115](https://github.com/nvaccess/nvda/issues/15115))

Braille line is also updated correctly when braille is tethered to focus. This is when there is text change but caret is not moved.

If you have suitable phrase for this, let me know, or if mentioning this is not necessary.

@LeonarddeR
Copy link
Collaborator

Good catch. SOmething like:;

  • When the text in a terminal changes without updating the caret, the text on a braille display will now properly update when positioned on a changed line. This includes situations where braille is tethered to review.

@seanbudd seanbudd added conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. and removed blocked/needs-product-decision A product decision needs to be made. Decisions about NVDA UX or supported use-cases. labels Aug 29, 2023
Copy link
Member

@seanbudd seanbudd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @burmancomp

@seanbudd seanbudd merged commit 7b31977 into nvaccess:master Aug 29, 2023
1 check was pending
@nvaccessAuto nvaccessAuto added this to the 2023.3 milestone Aug 29, 2023
@burmancomp
Copy link
Contributor Author

Thanks @burmancomp

And thanks @LeonarddeR as well.

@burmancomp burmancomp deleted the updateBrailleIndependentlyOnCaret branch August 29, 2023 05:32
seanbudd pushed a commit that referenced this pull request Sep 8, 2023
Fixes #15391
Fixup of #15163

Summary of the issue:
Since #15163, it is much more likely that braille tries to update a region for an object that no longer exists. This is no problem at all, however in that case, the region should simply be ignored for updating and a debug warning should be logged instead.

Description of user facing changes
No errors in de log while browsing

Description of development approach
a try/except around region.update, with an extra check to avoid updating regions for tree interceptors that have died.

Testing strategy:
Browsed with Firefox for some minutes, wasn't able to reproduce the issue any longer.
aaclause added a commit to aaclause/nvda that referenced this pull request Nov 12, 2023
aaclause added a commit to aaclause/nvda that referenced this pull request Nov 22, 2023
seanbudd pushed a commit that referenced this pull request Nov 23, 2023
Closes #15773
Fixup of #15163

Summary of the issue:
Contracted braille input is broken since #15163 merge.

Description of user facing changes
Contracted braille input works properly again.

Description of development approach
braille.handler._doCursorMove no longer exists. braille.handler._regionsPendingUpdate.add and braille.handler._handlePendingUpdate are used instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. merge-early Merge Early in a developer cycle
Projects
None yet
Development

Successfully merging this pull request may close these issues.

braille: update display when tethered to review and review cursor does not follow caret
8 participants