Add support for custom providers for braille display auto detection#14531
Merged
Conversation
See test results for failed build of commit f748e46ba0 |
See test results for failed build of commit 52662b1e0c |
Collaborator
Author
|
I'm pretty sure all these tests failures are unrelated. |
See test results for failed build of commit 7a36ab513c |
seanbudd
reviewed
Jan 16, 2023
seanbudd
reviewed
Jan 16, 2023
seanbudd
reviewed
Jan 16, 2023
| self._handlers = collections.OrderedDict() | ||
| self._handlers = OrderedDict[ | ||
| HandlerKeyT, | ||
| Union[BoundMethodWeakref[HandlerT], AnnotatableWeakref[HandlerT]] |
Member
There was a problem hiding this comment.
this type also might be worth turning into a named variable, as it is used repeatedly
Collaborator
Author
There was a problem hiding this comment.
Same issue as abbove, nesting TypeVars in variables doesn't seem to be respected by PyRight.
LeonarddeR
commented
Jan 16, 2023
LeonarddeR
commented
Jan 16, 2023
LeonarddeR
commented
Jan 16, 2023
seanbudd
reviewed
Jan 18, 2023
seanbudd
approved these changes
Jan 18, 2023
Member
|
@LeonarddeR can you address merge conflicts now that #14524 is merged |
Collaborator
Author
Done. |
See test results for failed build of commit 35813eaf81 |
LeonarddeR
added a commit
to LeonarddeR/nvda
that referenced
this pull request
Feb 16, 2023
6 tasks
seanbudd
pushed a commit
that referenced
this pull request
Feb 17, 2023
Fix for #14531 Summary of the issue: Error 'property' object is not iterable when enabling autodetect for the first time with Bluetooth on. Description of user facing changes None Description of development approach The detector was trying to save the bdDefsCache on the _DeviceInfoFfetcher class (not the instance).
6 tasks
michaelDCurran
pushed a commit
that referenced
this pull request
Mar 1, 2023
As part of Pull request #14531, I ordered display order in bdDetect alphabetically. However, it seems that querying Albatross first has a major negative impact on detecting other displays using the same Serial to USB converter (see Pull request #13045) Description of user facing changes Handy Tech displays such as the Modular Evolution instantly auto detect again. Description of development approach Restored the order, Albatross is last in the dictionary again. I'm pretty unhappy with how these displays work, but it looks like it's a design thing in the displays itself.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Link to issue number:
Related to #3564, #2315
Summary of the issue:
Currently, USB and Bluetooth devices are supported for braille display detection. Other devices using other protocols or software devices aren't supported. This pr intends to add support for this.
Description of user facing changes
Noone. User shouldn't experience anything different for now.
Description of development approach
Testing strategy:
As this touches braille display auto detection quite a lot, probably merge this early in the 2023.2 cycle.
Known issues with pull request:
bdDetect.Detector does no longer take constructor parameters, rather queueBgScan should be called explicitly. This is because if we queue a scan in the constructor of Detector, the detector could switch to a display and disable detection before the _detector was set on the braille handler. Ideally we should use a lock as well, but that might be something as a follow up for both this pr and #14524. Note that though we're changing the constructor of a public class in bdDetect, the doc string of the class explicitly states that the Detector class should be used by the braille module only. That should be enough warning for users not to use this class and therefore I don't consider this API breaking.
Change log entries:
For Developers
Code Review Checklist: