Re: holding off on 2022.1 due to Code Factory dragging their feet


Hi everyone,

A few clarifications before I crash with another headache:

Code Factory add-ons: while I cannot go into specifics, there was a last minute change made in NVDA 2022.1 to keep many add-ons compatible (specifically, control types refactor). I'm not sure if Code Factory is referring to this issue (a while ago someone posted that CF told folks that they are awaiting word from NV Access about code change in 2022.1), but I imagine that folks over there are working on compatibility updates.

Add-on update delays: it is normal to receive compatibility updates with a delay when stable NVDA versions are released, more so when we have a year.1 version (compatibility breaking release) in front of us. Without going into details, around the time NVDA 2022.1 beta 1 was around the corner, add-on authors wrote to NV Access about control types refactor (see the list archive from last year for an overview from me about this) and that can break more add-ons than anticipated. Therefore, NV Access decided to include a compatibility layer for old and new add-on releases, which is why add-ons may appear to work when you edit the manifest (addressed below). But for all practical purposes, NV Access recommends using the new control types code introduced in NVDA 2021.2.

As for manifests, as you read from Brian V a few minutes ago, working with manifests is a temporary workaround until the actual update declaring compatibility with the just released NVDA version becomes available. Why is this method a temporary workaround?

  1. 32-bit versus 64-bit Python: the reason why NVDA is a 32-bit application (for the most part) is because it is running on top of a 32-bit Python interpreter. There has been talks about moving to 64-bit Python (and consequently making NVDA a 64-bit screen reader), which requires a huge coordination between NV Access, add-ons community, users, and other stakeholders - similar to, or more than the work required to move from Python 2 to Python 3 (by the way, as of May 2022, building add-ons with Python 2 is no longer supported). Moving from 32-bit to 64-bit is not a simple matter of instaling a 64-bit Python interpreter and get it to run NVDA - it requires working with dependencies, including third-party libraries which can come in either 32-bit or 64-bit flavors, or in some cases, libraries needed to let 64-bit NVDA talk to 32-bit components and programs. Add-ons are not free from this - I would say add-ons require more work than the screen reader itself as they can come with components that are purely 32-bit (most notable being 32-bit speech synthesizer DLL's); on 64-bit Windows, you CANNOT let a 64-bit executable (.exe) talk to 32-bit DLL and vice versa without asking someone (another executable) to serve as a bridge and translate things on the fly (won't go into details as it is quite technical (low-level, literally) and don't want to go to the hospital right now). This becomes more important if your favorite add-on(s) use Python libraries with the extension of .pyd (Python extension DLL), and recent Python releases will load compatible DLL's (32-bit pyd for 32-bit Python and vice versa). So imagine a scenario where a 64-bit NVDA is released and you edit the add-on manifest, thinking that your favorite add-on(s) will work beautifully on both 32-bit and 64-bit NVDA. I'll leave it up to you to imagine what would happen when you restart NVDA.
  2. NVDA code can come and go: while the biggest under the hood change in NVDA 2022.1 (among other things) is control types refactor, there are things that can be introduced in future NVDA (and Python) releases that can make add-ons inoperable without editing the add-on source code. Imagine a new version of NVDA is released which is powered by a newer Python release (say, 3.10). Even if the add-on manifest edits appear to work and the add-on source code looks fine, it may not work correctly if it turns out it is using parts of Python that is no longer present or changed in some way. This becomes complicated if the add-on uses pyd files - Python will load pyd files that are compatible with: the version of Python you have and bit compatibility (32-bit Python 3.7 will load pyd files specifically designed for 32-vbit Python 3.7).

The biggest takeaway: EDIT MANIFESTS AS A LAST RESORT OPTION! Or, for that matter, DO NOT EDIT MANIFESTS, or if you must do it, first contact the add-on author BEFORE following what Brian wrote to you several minutes ago.

P.S. I once thought about instructing Add-on Updater (in the future) to present a message to anyone using add-ons with modified manifests but decided against as it is draconian and requires Internet access. But my sentiment remains: unless you know what you are doing, editing manifests should not be attempted prior to doing everything you can to contact the add-on author about updates. After all, it is not NV Access who has final authority on add-ons - the ultimate authority with add-ons rest with authors (including NV Access if they wrote add-ons you are using); my statement on who has final (and ultimate) authority on add-ons should also answer a question posed earlier: who to call when add-ons become unmaintained (contact the last known maintainer and/or the original add-on author (contact info can be found in Add-ons Manager) and then let the community know).

Thank you.

P.S. This might be the last time I will address this subject (for now; NVDA 2022.1 development and coordinating add-on compatibility while studying for grad seminars (which I passed, by the way) was rewarding and stressful; I didn't feel this tired and out of energy since 2016 while organizing NVDACon that year, ended up lying on my bed for a few days then).



Join to automatically receive all group messages.