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
Update braille independently on caret #15163
Conversation
See test results for failed build of commit b95da15196 |
See test results for failed build of commit 621db0d2a3 |
See test results for failed build of commit d33cb7f891 |
See test results for failed build of commit 2165a40281 |
See test results for failed build of commit 513924ae0f |
See test results for failed build of commit 4c50ada91e |
See test results for failed build of commit cca30e202a |
See test results for failed build of commit db74e0cddd |
See test results for failed build of commit 02c14674f5 |
See test results for failed build of commit c8f952a425 |
See test results for failed build of commit a6183d1bc7 |
See test results for failed build of commit b748d3f826 |
See test results for failed build of commit 0c530a1c6e |
See test results for failed build of commit 1c7b399611 |
See test results for failed build of commit ef8163f39d |
84be35d
to
8c947d9
Compare
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:
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 |
See test results for failed build of commit 19b4701ac9 |
Thank you @LeonarddeR for your comments.
What kind of event driven approach you are thinking?
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:
I suppose that most of time only above checks are done, and this is once in 0.5 seconds.
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? |
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. |
b3ef673
to
6a5b4d7
Compare
@burmancomp could you please add the following to tests/unit/__init__py, below
|
See test results for failed build of commit 7d68bd7314 |
See test results for failed build of commit 860a4c4d5e |
I'd like to suggest the following changelog entries: Changes:
Bug fixes
Changes for developers
Deprecations:
|
See test results for failed build of commit 9de47c2e25 |
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. |
Good catch. SOmething like:;
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @burmancomp
And thanks @LeonarddeR as well. |
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.
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.
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:
Description of development approach
Terminal window updates are handled with:
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
Bug fixes
For Developers
Deprecations:
Code Review Checklist: