toggle quoted messageShow quoted text
I too am just a User of code and have nothing to do with the construction of it.
However just as a User one of the celebrated strengths of NVDA is it ability to include add-ons which add functionality to the lives of many.
Breaking these add-ons compatibility is understandable with a major re-write as apparently happened last year but like others I have been disturbed at the repeated mass breakage which has appeared only months later, or so it seems to me.
I would appeal to have some consideration of how to prevent this becoming a routine annual event as it will undoubtedly strip away important functionality over time.
I would ask that this consideration is given especially as apparently simply changing the date in the manifest.ini file often resolves these issues , so it does not seem critical to my inexpert knowledge to NVDA that these add-ons be so ruthlessly excluded.
I have regained the addon for Mp3DirectCut, for example, a program I use multiple times a week with NVDA just by replacing the current NVDA version number in the addon.
It seems unnecessarily using a sledgehammer to crack a nut to knock out a working addon simply because it does not report the current NVDA version number in its manifest.ini fie.
As a final suggestion could not a routine – even dare I say it an addon be created which simply updates the version number in an NVDA addon manifest.ini file so these addons recover for some users. I accept that users would have to be warned/advised that simply changing the manifest.ini may not provide full addon compatibility in all cases and may result in unpredictable results. At least then however users would be able to make this decision rather than having the addon simply knocked out and excluded from their copy of NVDA.
Sent from Mail for Windows 10
19 July 2021 11:32To: email@example.comSubject:
Re: [nvda] Adding more add-ons to the core
I’m not sure if I understand everything you said properly. I hope these comments are relevant, nonetheless.
While I’m not advocating adding all sorts of add-ons to the core, I’m concerned that over time, increasing numbers of add-ons many people consider important may be lost as developers have to make them compatible time after time. Do you have a guess about how often this might generally be necessary? My recollection is that Firefox lost a lot of add-ons for this reason.
Perhaps my suggestion might be better phrased this way:
there are all sorts of demands on developers’ time and all sorts of competing needs or worthy and useful things that might be done. If this isn’t being done, it might be of considerable value to assess which add-ons are the most important and how practical it would be to add them, or equivalent functionality, to the core. It may be important to add the most important ones so they won’t be lost.
I don’t use it, but I suspect Golden Cursor is such an add-on.
Sent: Sunday, July 18, 2021 9:22 PM
Subject: Re: [nvda] Adding more add-ons to the core
[Edited Message Follows]
[Reason: typo fix]
I think it comes down more to the question of adding parts of add-ons rather than the entire add-on. Because add-ons derive their power from NVDA Core, it comes down to looking for changes between NvDA and add-ons themselves.
This task isn't easy for at least three reasons:
- As mentioned numerous times, the ability for an add-on to get itself running on recent NVDA releases depends on the attitude of add-on authors themselves. If authors are willing to keep up based on documentation from NvDA (namely what's new document and code samples coming from others in the development community), then add-ons will be updated.
- Different authors use different ways to express code. Although Zen of Python advises folks to strive for one solution, there are different ways to do things. For example, people can go through a list of records using either a for loop or a while loop, or if one gets into advanced mode, perhaps using container comprehensions (comprehensions come from functional programming; way advanced for the scope of this list, I'm afraid). There is a common coding standard NVDA contributors are expected to follow (such as using tabs to denote indentations), but not all add-on authors use this style (if they did, it will make life a lot easier, but folks have different ways to express themselves, and I think that should be respected).
- Add-ons patch things here and there. In some cases, add-ons would come with their own implementation of a core NVDA feature or two (the best known example is Remote Support add-on). If an add-on patches an NVDA feature or two that other add-ons rely on, it creates a situation where other add-ons you've got may not work properly. Although folks may think patching NVDA Core may help in getting add-on code to resemble NVDA code, it does not - rather, it makes it difficult to separate the differences between what is core versus add-on. For this reason, whenever I need to override some NvDA functionality, I always include a comment that helps me remember that I need to look for ways to not disturb other add-ons (Windows App Essentials is a good example of an add-on with such comments) and do my best to call NVDA feature itself in the end.
Here is a list of parts of add-ons that ended up in NVDA itself as far as I know (spoiler: this list includes current NVDA alpha builds):
- Screen Curtain: originally devleoped by Leonard de Ruijter (formerly of Babbage), I packaged it into an add-on, knowing that NV Access, too was thinking about incorporating this feature into NVDA in the end. After months of public testing, it did become part of NVDA 2019.3.
- Enhanced Aria: originally developed by Jose Manuel Delicado, the ARIA article landmark constatn became part of NVDA 2019.3.
- Focus Highlight: originally developed by Takuya Nishimoto, most of its features (now known as Visual Highlight) became part of NVDA 2019.3.
- Enhanced Touch Gestures: the following parts of my add-on became part of NVDA in recent releases: toggling touch support, mouse right click touch gesture (one finger tap and hold), and touch typing mode where you can toggle between lifting your finger or a double-tap to enter text via touch keyboard.
- OCR: a different implementation is used on Windows 10 and 11 that has nothing to do with the recognition engine that originally shipped with the original add-on (OCR add-ons was originally developed by NV Access).
- NV Speech Player: although not part of NvDA directly, the Edward voice is part of eSpeak NG that ships with NVDA 2021.1 (if I remember correctly).
- Resource Monitor: I noted a few days ago that parts of at least two add-ons will be part of future NVDA releases, and one of them is Resource Monitor. Specifically, Windows release information internals is now part of NVDA (as of alpha builds), and for those reading NVDA source code, NVDA now has the ability to detect which Windows 10 or 11 release you are using via Windows Registry (this part came from Resource Monitor).
- Windows oneCore voices: formerly known as Microsoft Mobile voices, this synthesizer was originally an add-on (developed by Tyler Spivey) before making its way to NVDA.
- Windows App Essentials: over the years, many parts of this add-on (from me) were included in NVDA. These include modern keyboard facility (emoji panel/clipboard history/dictation/voice typing/hardware keyboard suggestions), announcing search suggestions if present, UIA notification event support, and countless small things here and there. In fact, parts of the add-on made their way to recent NVDA alpha snapshots, including Windows 11 detection and support.
- Add-on Updater? Maybe... (behind the veil at this time)
As for the procedure I use in add-on development: I keep a close eye on changes in alpha and beta releases, and to some extent, NVDA pull requests that are being worked on by NV Access and contributors (including my own). As a result, at least for Windows App Essentials, it contains code that responds to latest NvDA alpha snapshots, including the next big thing for add-on authors to consider: control types refactor (I won't go into this change, but suffice to say that control types refactor (involving a syntax change) will affect many add-ons, and I have advised add-on authors to prepare their add-ons).
Hope this helps.