Added a Development Guide chapter describing and listing extension points#14810
Conversation
|
A huge thanks! It's definitely a topic to expand and spread. |
|
Is this ready for review? |
This comment was marked as outdated.
This comment was marked as outdated.
…les (#14811) Summary of the issue: While working on #14810, I found several places where comments about the core extensionPoints could be made clearer, or had typos/capitalization errors/questionable grammar. Description of user facing changes None. Description of development approach I fixed them as I went along, and scooped them all into their own branch. Here is the result. I changed no code in this, and nothing structural has been altered. That is, where #: style comments were used in some places, and docstring style comments in others, I left them that way. I'm not actually sure what we prefer now. I wasn't trying to lint anything, just fix language.
…listing types, and listing defined points. (#14810)
|
@seanbudd This should be ready now. I still question whether the |
seanbudd
left a comment
There was a problem hiding this comment.
Thanks @XLTechie, these documents generally look good to me.
I think it's worth keeping the vision extension points as they are part of the public API.
We can always improve the documentation on using these extension points in the future.
Co-authored-by: Sean Budd <seanbudd123@gmail.com>
See test results for failed build of commit 1272d22454 |
seanbudd
left a comment
There was a problem hiding this comment.
Thanks, other than code formatting this looks good to me
| | ``Filter`` | ``filter_displaySize`` | Allows components or add-ons to change the display size used for braille output. | | ||
| | Action | displaySizeChanged | Notifies of display size changes. | | ||
| | Action | pre_writeCells | Notifies when cells are about to be written to a braille display | | ||
| | Action | displayChanged | Notifies of braille display changes. | | ||
| | Decider | decide_enabled | Allows deciding whether the braille handler should be forcefully disabled. | |
There was a problem hiding this comment.
there inconsistent code formatting here. I think it might be worth committing to code formatting for all NVDA python symbols
|
there inconsistent code formatting here. I think it might be worth committing to code formatting for all NVDA python symbols
Sorry, I thought I got all of that. I wonder if I dropped a commit somewhere
while rebasing or merging test vs. submission branches.
Will fix shortly.
|
|
there inconsistent code formatting here. I think it might be worth committing to code formatting for all NVDA python symbols
@seanbudd Ready for re-re-re-review.
|
Link to issue number:
Closes #14648
Summary of the issue:
There is currently no definitive list of all available extension points. Since these seem to be the preferred future direction for add-ons and other code to interoperate with NVDA internals, it would be valuable to include a list of them in the Developer Guide.
It would also be valuable to include various examples and further documentation there, but that can come in a later PR.
Description of user facing changes
None.
Description of development approach
extensionPoint" in the source.Testing strategy:
Submission of this PR is the test.
Known issues with pull request:
I am so far unclear how to best represent the chained extensionPoint
scanForDevices, inbdDetect.py.I have also not yet written entries for the factory-defined extensionPoints in
vision/visionHandlerExtensionPoints.py. I haven't figured out why it was designed this way, and until I do, I'm not sure I will be describing them accurately.Change log entries:
For Developers
All NVDA extension points are now briefly described in a new, dedicated chapter in the Developer Guide.
Code Review Checklist: