Faster add-on development workflow #5199
Comments
|
Comment 2 by jteh on 2015-07-08 04:28 I'm rather reluctant to add anything like this to the public API because while it's useful for development, public callers generally shouldn't be asking for this kind of information. I'm concerned it'll lead to external apps trying to make config changes or the like, and while they can already do that, it's at least not "encouraged" by the API. That said, I guess we could consider some sort of private API if that's really necessary. I also think this should be named scons devInst or fastInst or something like that so it's clear it isn't a normal installation. For example, it doesn't run installTasks, etc. For reference, there are three possible places NVDA can store its configuration:
|
|
cc: @feerrenrut |
|
cc: @michaelDCurran |
|
II think I'll close this. At the moment you can use the scratchpad to avoid having to install the addon. You could link the directories as Jamie suggested, or you could use a directory synchronization tool to keep the scratch pad in sync with the addon repo. If you do this, then working on an addon from an IDE (opening the NVDA source code as a project, with the addon synchronized with the scratchpad directory) allows you to get hinting and instantly start and test the addon. I think the first step should be for the addon community to get together docs on the suggested workflow for addon authors. From beginning to end. This will help to identify the friction points and we can work to do something about it. |
Reported by Q on 2015-07-06 20:11
Currently, the options for developing an NVDA add-on consist of:
1: Create and work on the add-on in your standard code directory.
This is how I'd like to work, but it has some pretty major downsides.
When working on the code, test, debug lifecycle, the necessity of constantly having to run scons, then install the add-on and answer yes three times for every single change becomes incredibly wearing.
2: An ugly hack that several people have suggested is to place the actual add-on code into the add-ons directory and work on it there. This means not having access to the version control while working on the code, and manually having to copy code back and forth to the git repo. It's also just sort of downright ugly.
I suggest an improved version of 1:
If we can figure out where NVDA data should go, either by asking NVDA itself, asking the user, or even just guessing, we can automatically install the add-on without prompting the user. NVDA already has the ability to force restart. I propose a scons install command in the default add-on template, which may need to call infrastructure in the core to accomplish what it needs to to get the add-on installed and the current NVDA restarted.
I'm opening this here as my conversation with @joslee lead me to believe that this will need at least a bit of work in core.
The text was updated successfully, but these errors were encountered: