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

braille: update display when tethered to review and review cursor does not follow caret #15115

Closed
burmancomp opened this issue Jul 10, 2023 · 5 comments · Fixed by #15163
Closed
Labels
component/braille-ux User experience for braille p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Milestone

Comments

@burmancomp
Copy link
Contributor

burmancomp commented Jul 10, 2023

Is your feature request related to a problem? Please describe.

Sometimes it would be useful if braille display content would be updated automatically although braille is tethered to review and review cursor does not follow caret. This might help when using terminal software like Teraterm or Putty in non-graphical Linux server environment.

Describe the solution you'd like

Advantage or disadvantage is at the moment that user action is needed to update display. Is it advantage or disadvantage depends on case. Maybe there should be a setting but this should be discussed.

Describe alternatives you've considered

Slightly modifying handleCaretMove in review.py.

Additional context

When review cursor does not follow caret, moving it to next/previous character may give strange results. However this should not depend on braille display updating so I suppose that it should be a separate issue. Solution for that might have something to do with wideToStrOffsets in textUtils.py.

@seanbudd seanbudd added p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation. component/braille-ux User experience for braille labels Jul 10, 2023
@burmancomp
Copy link
Contributor Author

@LeonarddeR do you have thoughts how this should be implemented?

@burmancomp
Copy link
Contributor Author

Because task is to update display automatically when current navigator object content changes, implementation would seem to be quite simple, especially if it is acceptable that current behavior changes.

A setting would be possible to keep current behavior but it would likely require much more code than updating braille line automatically. Generally I prefer to implement a setting because then user can decide but it is normal that display is updated, so in this case a setting sounds somewhat redundant or at least I am somewhat unsure.

To summarize: a setting or behavior change?

@LeonarddeR
Copy link
Collaborator

I'm afraid I don't understand the issue. Could you provide a real life scenario along with what you'd expect and what happens instead?

@burmancomp
Copy link
Contributor Author

burmancomp commented Jul 11, 2023

I'm afraid I don't understand the issue. Could you provide a real life scenario along with what you'd expect and what happens instead?

When you want to monitor what happens in given line without caret movement disturbing. Considering especially non-graphical user interface (like Linux server environment command line (shell like bash)) which can be used remotely with terminal software like Putty or Teraterm.

Screen is explored with review cursor. Braille tethered to review. When exploring screen it is useful that cursor movement does not move review position (review does not follow caret) but if review does not follow caret and braille is tethered to review then display content is not updated automatically.

"Progress bars" could be an example. Cursor may be located mainly on next line but information is updated to line which is one line above. Setting "does not follow caret" gives possibility to monitor that above line but braille line content is not updated automatically.

Why "review cursor does not follow caret" should block braille line updating when cursor movement (movement may occur also when editing text, printing something to screen) changes content of current navigator object/that part of it which display is showing.

There are situations when this is useful but as I wrote in my previous comment I am unsure if there should be a setting or not.

@burmancomp
Copy link
Contributor Author

I edited my previous comment because "check box" "[ ]" state would not be updated automatically because pressing spacebar does not cause cursor movement. If pressing enter would change state and move focus to next item then state change should be updated.

@nvaccessAuto nvaccessAuto added this to the 2023.3 milestone Aug 29, 2023
seanbudd pushed a commit that referenced this issue Aug 29, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/braille-ux User experience for braille p5 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority triaged Has been triaged, issue is waiting for implementation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants