Open hwf1324 opened 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
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
Some thoughts:
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.
The scratchpad has some limitation with respect to a real add-on folder:
@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.
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