Hi all,

The NVDA Add-on Development Guide has been updated:

https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide

New in this version:

• Fixed some misspellings.
• In Appendix D, added entries on how to retrieve IAccessibleObject and UIAElement.

Notes about certain items added in Appendix D:

• I want to contribute features of my add-on to NVDA screen reader: you need to send in a pull request to NVDA and ready to answer review questions. But first, be sure to go over issues from https://github.com/nvaccess/nvda/issues to make sure you are not creating a duplicate issue. Also, be sure to test your code thoroughly (yes, thoroughly) before sending in a pull request, especially given changes made to release process in recent days.
• I wish to bring a feature from another screen reader to NVDA: be sure to provide a justification or two. These must be solid, compelling, and worthy of a community project. Questionable justifications include saying things like, “just because this and that screen reader has this and that feature” without giving very good reasons, “because I like this feature from this and that screen reader” without providing use cases that’ll have community impact, and “I want NVDA to have greater market share thanks to this and that feature” without going into solid details as to why (when I’m asked to review pull requests like these, I’ll surely ask for justifications).
• I want to release version 1.0 of my code with everything included: don’t do it unless you know why, know what you are doing, or specifically mentioned in a contract you agreed to. While doing everything in 1.0 is a worthy effort, it requires more precise planning.
• I wish to make my code run faster and error-free: NEVER, EVER DO THAT UNLESS YOU HAVE TO OR KNOW WHAT YOU ARE DOING! Please don’t even think about doing such a thing or struggle with minimizing errors until you create a working solution, and then think about it when the opportunity presents itself (trust me, I fell into premature optimization trap many times). If you truly wish to make your code run faster and/or minimize errors, be prepared to gather more data than calling time.time() function and printing what it gives you or assume that you can’t reproduce the bug people are reporting (I’d be happy to discuss tricks you can use to optimize your NVDA add-ons if there is sufficient demand on the add-ons list).

One more question which I’ll add to 2018.3 edition of this guide (August):

• I wish to just ship pyc/pyo version of my add-on: first, that’s illegal in the eyes of GPL (unless you are given exceptions), and second, a skilled programmer can reconstruct the source code by disassembling it, inspecting it via Python Console and what not. Also, add-on reviewers need the source code of your add-on to help them review your solution(s) better. So if you do offer an add-on to the community and provide only a compiled file, chances are that reviewers will insist on having the source code in front of them (for add-ons I’m asked to review, an add-on without its source code will receive an automatic “basic review rejected” notice because without that, basic review cannot be done).

Thanks.

Cheers,

Joseph