Skip to content

Added a Development Guide chapter describing and listing extension points#14810

Merged
seanbudd merged 17 commits into
nvaccess:masterfrom
XLTechie:fix14648
Apr 19, 2023
Merged

Added a Development Guide chapter describing and listing extension points#14810
seanbudd merged 17 commits into
nvaccess:masterfrom
XLTechie:fix14648

Conversation

@XLTechie

@XLTechie XLTechie commented Apr 8, 2023

Copy link
Copy Markdown
Collaborator

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

  • Created a new chapter in the Developer Guide, describing very briefly what extension points are, mainly as a concept introduction. This could stand to be expanded significantly.
  • Used grep to find all occurrences of "extensionPoint" in the source.
  • For each one, determined why the module was being imported, and if it was actually used to create an extension point, added appropriate entries to the dev guide describing that extensionPoint.

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, in bdDetect.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:

  • 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.

@ABuffEr

ABuffEr commented Apr 8, 2023

Copy link
Copy Markdown
Contributor

A huge thanks! It's definitely a topic to expand and spread.

@XLTechie XLTechie changed the title Add a Development Guide chapter describing and listing extension points Added a Development Guide chapter describing and listing extension points Apr 8, 2023
@seanbudd

Copy link
Copy Markdown
Member

Is this ready for review?

@XLTechie

This comment was marked as outdated.

seanbudd pushed a commit that referenced this pull request Apr 11, 2023
…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.
@XLTechie XLTechie marked this pull request as ready for review April 13, 2023 09:13
@XLTechie XLTechie requested a review from a team as a code owner April 13, 2023 09:13
@XLTechie XLTechie requested a review from seanbudd April 13, 2023 09:13
@XLTechie

Copy link
Copy Markdown
Collaborator Author

@seanbudd This should be ready now. I still question whether the vision section (the last section) should be there at all, since those aren't supposed to be directly used (if I understand the code accurately).
I wouldn't be opposed to you tossing that part if you think it confuses the issue.

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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.

Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
Comment thread devDocs/developerGuide.t2t Outdated
@AppVeyorBot

Copy link
Copy Markdown

See test results for failed build of commit 1272d22454

@XLTechie XLTechie requested a review from seanbudd April 14, 2023 10:15

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks, other than code formatting this looks good to me

Comment thread devDocs/developerGuide.t2t Outdated
Comment on lines +977 to +981
| ``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. |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

there inconsistent code formatting here. I think it might be worth committing to code formatting for all NVDA python symbols

@XLTechie

XLTechie commented Apr 18, 2023 via email

Copy link
Copy Markdown
Collaborator Author

@XLTechie

XLTechie commented Apr 18, 2023 via email

Copy link
Copy Markdown
Collaborator Author

@seanbudd seanbudd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks @XLTechie

Comment thread devDocs/developerGuide.t2t Outdated
@seanbudd seanbudd merged commit e6dc684 into nvaccess:master Apr 19, 2023
@nvaccessAuto nvaccessAuto added this to the 2023.2 milestone Apr 19, 2023
@XLTechie XLTechie deleted the fix14648 branch April 19, 2023 06:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

List, and eventually document, all available Extension Points

5 participants