---------- Forwarded message ---------- From: Joseph Lee <[email protected]> Date: Thu, 11 Jun 2015 10:15:49 -0700 Subject: [NVDA] Behind the scenes tour of NVDA feature and add-on development To: [email protected]
Hi NVDA land citizens, Since someone asked about how NVDA development works and to let you have some entertainment as we wait for NVDA 2015.2, I'd like to give you a behind the scenes look at how an NVDA feature or add-on is born. Specifically, I'll use two examples: a feature added recently into NVDA and a feature from one of my prized add-ons: Case-sensitive find and Track Dial from StationPlaylist Studio add-on, respectively. NVDA follows typical software development processes: issue identification, requirements analysis, coding, testing, release and maintenance. Some of the phases below overlap and some may not follow this pattern (majority of them do). Phase 1: Issue identification and preparations: Someone raises an issue - a bug report, feature suggestions and so on. This can be done in numerous ways, including posting your suggestions here, creating a ticket on NVDA Community portal, raising issues with NVDA here or on the development list (nvda-devel) and so on. Once developers receive suggestions, one of us will look into it by asking follow-up questions (more on that at the end), trying to reproduce the issue or doing further research. Once a solution is identified, either NV Access (Mick Curran or Jamie Teh) will work on it or a third-party developer (a company, an individual or a group of them) will work on a solution. In case of case-sensitive find, the suggestion was to let a user perform case-sensitive find. Jamie from NV Access told potential developers that there was a way to do this, and I decided to work on it for a few days. For Track Dial, a broadcaster using StationPlaylist Studio suggested enhanced arrow keys feature, and I spent several weeks researching and coming up with a solid solution. Phase 2: Development and testing: Once either NV Access or a third-party (or a group of them with or without collaboration from NV Access) decides to tackle an issue, the developer will spend some time writing the solution (more on specifics with branches in a second). Next, the developer will repeatedly test the solution, refining it, coming up with new solutions or making related changes to NVDA source code to make the solution work. Once that's done, testing begins, first by the developer, then by users. In case a third-party wrote the solution to the issue, he or she (or the company or a group) posts a patch or a link to a branch for code review. Code review can be done by anyone (I sometimes do code review for my specialty areas, which are touchscreens, some GUI elements and documentation, although I do reviews of other subsystem code). Once developers perform code review and if NV Access decides it is good quality code, it'll be included in NVDA, first for testing, then release afterwards. For case-sensitive find, I decided to start with looking at existing code for NVDA's find dialog (Control+NVDA+F). I noticed that the code used allowed only text entry, so I set out to write a new dialog code that adds a checkbox for case-sensitive find. After writing my solution, I tested it, but found that it wasn't working right, which turned out to be a call to a wrong function. Once that was fixed, I tested again, and posted my code for others (including NV Access) to review. Once my code was accepted, it went into NVDA's next snapshots, which eventually made it into NVDA 2015.1. For Track Dial, I set out to use one particular solution. Although it was working for some corner cases, I knew this wasn't the perfect solution. Then I investigated a piece of code from NVDA Core (NVDA itself) that dealt with list views where one can navigate columns using table navigation keys (Control+Alt+arrows), and found that code to be the more perfect solution. I tested this code in my add-on (modifying it to fit feature requirements), then proceeded to write the more solid solution. After testing this on multiple SPL versions, I sat down one day to think about a descriptive name for this feature. I thought, "if I want NVDA to gain traction, I needed to give this a name that'll evoke something related to broadcasting and set NVDA add-on for SPL apart". I quickly dismissed "enhanced arrow keys", as it was too common. I eventually settled on the name "Track Dial" because the feature I developed evokes using dials on radios to change channels (Track Dial lets you review track columns using arrow keys; the toggle command is unassigned by default, which is another distinguishing characteristics of NVDA add-on for SPL). The feature itself is now included in StationPlaylist Studio add-on for NVDA 5.0 (currently a release candidate, to be released hopefully by end of June). Phase 3: release and maintenance: Once the feature is accepted, it'll be released as part of the next version of NVDA. Over time, the feature developer may enhance the feature (it could be NV Access, a third-party developer or a company, etc.), or in some cases, will be removed because it no longer meets the requirements of users or is superseded by something else. FAQ's: * Can anyone develop a feature? Yes, anyone with knowledge of Python, NVDA and a good grasp of coding and testing can develop anything. * Doesn't a feature development involve funding? For high-profile features, yes. A good case was support for writing Chinese, Japanese and Korean characters in NVDA. * Who has ultimate control over acceptance of a feature? NV Access, and by extensions, users themselves (especially users who have suggested it in the first place). * Can code from add-ons be included in NVDA core? Yes. Some features start their lives as an add-on, and were accepted into NVDA itself. Now there are websites which hosts older add-ons where code was included into NVDA itself, and because of this, these add-ons should not be used. Sometimes an add-on is made of existing code from NVDA, either to enhance it somewhat or to provide a completely different implementation of a feature (TeamTalk add-on from Doug Lee is a good example of the first case). * How long will it take for my suggestion to become an NVDA feature? It varies. Some take at least two weeks, while others can take years. * If a third-party is writing support for a program, what would be the best route to take? First, see if someone has created a ticket for supporting the app in question. Then do one of the following: 1. If you want to use NVDA core source code and are familiar with Git version control system, then create your solution as a patch. 2. On top of this, if you have a public repo, create a branch to house your solution and provide a link to your repo and the branch name when submitting your code for review. 3. Create an add-on that supports a new program (an app module), have it reviewed by community add-on reviewers and let users know that your add-on supports the program in question. If the add-on addresses a ticket, please provide a link to that ticket so the add-on code can be included in NVDA. As always, you are more than welcome to find funding for your feature. * I'm desperate to write a feature. What should I do? First, don't panic. If you are serious about developing an NVDA feature, you should work on it. But an important prerequisite must be met: learn Python first. I've seen cases where some NVDA add-on writers write add-ons without having a basic grasp of Python, which is essential to your success as a contributor to NVDA project. One more thing you need to keep in mind (always): your code can change life of a blind person halfway around the globe, so develop your feature with care, and always communicate with users and other developers to stay current and to write a solution that'll benefit not only the user who requested it, but others who may follow your footsteps a few years later (who might be reading your code). Any other development questions should be sent to NVDA Development list (nvda-devel). Add-on questions are welcome at NVDA Add-ons list (nvda-addons) hosted on Freelists. Thank you. Sincerely, Joseph S. Lee Twitter: @joslee Facebook: josephsl (where you can find my musings and piano videos) Blog site: Musings of a Blind Highlander: http://joslee22590.blogspot.com/ ---------------------------------------- NVDA on freelists.org To post messages to the list send email to [email protected] To leave the list, send a blank message with the subject of "unsubscribe" (without quotes) to [email protected]. Reply to the confirmation message or click the link provided by the email. To modify your NVDA Email settings or view archives: Modify list subscription settings: http://www.freelists.org/list/nvda NvDA list archive: http://www.freelists.org/archive/nvda To contact list moderators, send an email to [email protected]. NVDA is developed by NV Access in collaboration with the community. Get NVDA from: http://www.nvaccess.org/ Your continued donations help keep NVDA development going strong. Donate at: http://www.nvaccess.org/donate Other links: Come talk with other NVDA users on irc.blufudge.net #NVDA Get NVDA add-ons at: http://addons.nvda-project.org/ NVDA on Facebook: http://www.facebook.com/group.php?gid=8601265515 Get SkypeTalking for NVDA: http://skypetalking.googlecode.com/ -- Warm Regards Bhavya Shah Using NVDA (Non Visual Desktop Access) free and open source screen reader for Microsoft Windows To download a copy of the free screen reader NVDA, please visit http://www.nvaccess.org/ Using Google Talkback on Motorolla G second generation Lollipop 5.0.2 Reach me through the following means: Mobile: +91 7506221750 E-mail id: [email protected] Skype id : bhavya.09 Register at the dedicated AccessIndia list for discussing accessibility of mobile phones / Tabs on: http://mail.accessindia.org.in/mailman/listinfo/mobile.accessindia_accessindia.org.in Search for old postings at: http://www.mail-archive.com/[email protected]/ To unsubscribe send a message to [email protected] with the subject unsubscribe. To change your subscription to digest mode or make any other changes, please visit the list home page at http://accessindia.org.in/mailman/listinfo/accessindia_accessindia.org.in Disclaimer: 1. Contents of the mails, factual, or otherwise, reflect the thinking of the person sending the mail and AI in no way relates itself to its veracity; 2. AI cannot be held liable for any commission/omission based on the mails sent through this mailing list..
