nvda icon indicating copy to clipboard operation
nvda copied to clipboard

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

Open hwf1324 opened this issue 1 year ago • 4 comments

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

hwf1324 avatar Oct 02 '24 07:10 hwf1324

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

seanbudd avatar Oct 02 '24 07:10 seanbudd

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

hwf1324 avatar Oct 02 '24 07:10 hwf1324

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

CyrilleB79 avatar Oct 02 '24 07:10 CyrilleB79

@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.

XLTechie avatar Oct 02 '24 10:10 XLTechie

Just for the record, if the add-on is developed using the community's Add-on template, my current approach is to create file links to mitigate this use case.

cd <addonFolder>
scons
mklink /j <userConfig>\addons\<addonId> <addonFolder>\addon

Please replace the <> placeholder with the actual path.

hwf1324 avatar Nov 10 '25 14:11 hwf1324

my current approach is to create file links to mitigate this

Same.

Danstiv avatar Nov 10 '25 14:11 Danstiv