Re: I am interested in programming for NVDA
I might add to Joseph and say that working with NVDA and publishing it doesn’t just require a knowledge of programming in Python, but also about various software engineering concepts as well.
Software engineering is a wide spectrum of skills that include the essential steps of software design and development, but also cover wider aspects such as maintenance, testing and release.
Of course the simplest form of this is what many single small-time developers do: Have an idea, program it, test it on one machine, upload, write your web page, and it’s released. This is how I have worked for the past 14 years.
The change started last year, when I collaborated with someone on a game – my first introduction to source code management – versioning, bug tracking with tickets, wiki systems and all that good stuff. We used a system called Fossil, which is a self-hosting system which even has its own in-built server, wiki and ticket system.
Working with NVDA addons, I then had to learn the art of yet another versioning system, which was different from its host platform, I.E. Git and GitHub. While Git does the actual versioning, GitHub hosts the Git data and also provides the means for the bug tracker, ticket and release systems, while also providing a code moderation system and social media features.
NVDA itself also makes use of several other engineering components that provide automated building and testing, so if you want to be a major contributor I’m guessing those will also need to be learned. SCons, a Python code autobuilder, is definitely a plus.
It does sound amazingly complicated, and even I don’t understand the build/test process, which I believe is done through AppVeyor, but I have often thought my mind would positively explode with all the new things I had to learn just to slowly wriggle through the basics. It’s been a long haul, taking me over four years to be able to learn enough to write and publish my first addon.
Now that I’ve done that though, that’s only given me the determination to launch the ship I have built. I myself have had an in-depth look at the source code so that, hopefully, I too can contribute directly to the NVDA code.
From: Joseph Lee
Sent: Friday, August 11, 2017 1:22 AM
Subject: Re: [nvda] I am interested in programming for NVDA
I’d say we should discuss some basics here for the benefit of many on this forum who wants to contribute code to NVDA.
First things first: before people learn the intricacies of NVDA source code, some knowledge of Python is essential. If Stephanie came onboard last year, I could have told her to learn Python 2; however, times have changed, and I recommend people who are newbies to learn Python 3. For most tasks, Python 2 and 3 will work well, but there are some internal things that require you to become familiar with Python 2 for a little while before NV Access declares transition to Python 3.
Most of us (including I) started out with writing NVDA add-ons. Some of the add-ons out there, including Enhanced Touch Gestures, Clock, and many others were written by developers prior to their exposure to internals of NVDA source code. Learning to write NVDA add-ons helps some people in practicing Python skills and getting to use high-level functions offered by NVDA.
It is indeed possible to modify NVDA source code with zero to limited knowledge of Python. But when it comes to actually digging into code and providing contributions, this quickly becomes an overwhelming task because not only a new programming language must be learned, but also one needs to know how certain things in NVDA works behind the scenes (via source code). This is one of the reasons why I always advise scripters of other screen readers to take some time off and learn Python before working on seriously transforming their scripts to NVDA add-ons.
In terms of what you need to know before seriously working on NVDA code contributions:
Things you won’t learn right away but will be fruitful later:
The items listed above are some of the activities a typical large software engineering team (such as NVDA developers) go through, especially for an international community like ours. I personally place higher emphasis on design and explanations. In case of feature explanations, this is the reason why I always ask add-on writers to write up a short readme explaining how to use their add-ons.
One of the things I did, which not only benefited the community but also something I enjoyed doing (and wanted to do for a while), is writing add-on internals. Basically, I would sit down in my “lab” (in front of my computers at home), sip through add-on source codes and think about the overall design of the add-on, its purpose, and what authors would have felt when they wrote add-ons. These notes, along with handy references were collected into an article that varies in length from an essay (four or five pages) to a thesis that’s suitable for graduate schools sort of (more than 70 pages long) depending on my overall familiarity with the add-on and if certain features need deeper exploration and explanation. This opportunity also gave me a chance to study the NVDA screen reader source more deeply, which became the basis for an idea I have about organizing a six month long course on diving into NVDA source code (in the book form, it’ll span at least a hundred pages, possibly more); I say “six months” due to vast amount of knowledge the NVDA source code contains, as well as give background info and explain the rationale behind some design choices made, along with some breaks in between.
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of swwatts3@...
Hi Joseph and Tony,