nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 638 forks source link

Add-on: Adds an unpackaged Add-on to facilitate the development and testing of Add-ons. #17239

Open hwf1324 opened 1 month ago

hwf1324 commented 1 month ago

Is your feature request related to a problem? Please describe.

Currently we can develop Add-on's on an ad-hoc basis via the scratchpad catalogue, but there are several problems with this.

When we want to test the Add-on on different versions of NVDA, we may need to copy and paste the modified original file frequently. Especially if you need to interact with applications that have administrator privileges.

There is also the inconvenience when we want to develop and test the source code of an Add-on cloned from GitHub.

Describe the solution you'd like

For cases where a complete Add-on structure exists, you can manually specify the unpacked Add-on directory from which to load the Add-on, and perhaps also the corresponding manifest.ini

When there is no manifest.ini, this directory behaves like scratchpad.

Describe alternatives you've considered

Manually create hard links without NVDA processing.

Additional context

Follow-up to #6277

seanbudd commented 1 month ago

Thanks for opening this. I have a couple of clarifying questions

When we want to test the Add-on on different versions of NVDA, we may need to copy and paste the modified original file frequently.

If you are doing this from source, and keeping the file in the scratchpad, wouldn't you just need to git checkout the release tag of NVDA you want, without copy/pasting?

There is also the inconvenience when we want to develop and test the source code of an Add-on cloned from GitHub.

Can this be fixed by cloning into the scratchpad dir? If that can't be done now, it would be a useful structure to support

For cases where a complete Add-on structure exists, you can manually specify the unpacked Add-on directory from which to load the Add-on, and perhaps also the corresponding manifest.ini

Where would you like to specify this? Can you elaborate more on the UX. My proposal on #6277 was to add something to advanced settings to allow adding additional scratchpad directories

hwf1324 commented 1 month ago

If you are doing this from source, and keeping the file in the scratchpad, wouldn't you just need to git checkout the release tag of NVDA you want, without copy/pasting?

Yes, I should add cases where I need to interact with applications that have administrator rights.

Can this be fixed by cloning into the scratchpad dir? If that can't be done now, it would be a useful structure to support

Unless the repository's root directory holds the Add-on source code, and only the individual Add-on types, this should be unlikely.

Where would you like to specify this? Can you elaborate more on the UX.

For the presence of manifest.ini, I'm not sure. add-on store or add-on store settings panel might be good.

My proposal on #6277 was to add something to advanced settings to allow adding additional scratchpad directories

For the scratchpad directory, I agree with the

CyrilleB79 commented 1 month ago

Some thoughts:

  1. To test with various versions of NVDA, it's often much quicker to have many installers or portable versions and to pass them the same -c path\to\config parameter.

  2. The scratchpad has some limitation with respect to a real add-on folder:

    • no possibility to call init translation function
    • no possibility to test two or more add-ons in the same time (except if you mix their files)
    • To be checked: maybe the new addition of symbol dictionaries is not supported since it needs the manifest
XLTechie commented 1 month ago

@seanbudd

  When we want to test the Add-on on different versions of NVDA, we may need to copy and paste the modified original file frequently.

If you are doing this from source, and keeping the file in the scratchpad, wouldn't you just need to git checkout the release tag of NVDA you want, without copy/pasting?

What I'm getting, is that he develops, using many add-on source files, under a source checkout, but tests in a separate installed copy (or several of them? Somehow?).

In that scenario, the installed copy isn't git-managed, so I don't see how your solution would work there.

Being able to setup additional scratchpad directories, would allow pointing the directory in several NVDA copies, to a single place.

For the reasons @CyrilleB79 pointed out, I don't develop complex stuff in the Scratchpad personally.

Maybe an "Additional add-on paths" option would be better? Allowing the search for externally installed add-ons to be expanded to manually entered directories.

The UX, then, would be a simple path chooser under either Advanced, or the Add-on store panel.