cfillion
commented
1 year ago I think the best way to address this FR would be an API for scripts to register their "generated files" (naming TBD...) with ReaPack. Then, when the user uninstalls something, ReaPack could prompt what to do with those files (eg. a list with delete checkboxes) in a generic UI.
I have several concerns with running arbitrary scripts:
- Scripts run in the main thread, blocking REAPER. Not an issue right now because ReaPack is also guilty of that, but will be once I get to work on the next version (I want to move all work–except action list registrations–to a background thread). Firing possibly > tens of hook scripts in the UI thread would be against that goal.
- Extensions cannot (reliably) tell when a deferred script finishes
- User interface and behavior would be inconsistent between each of those uninstall hook
- Bugs in those third-party hooks would affect ReaPack's reliability
- Could do things that don't belong in an uninstall process
Not terribly useful for discrete actions of course, but for long-running scripts that provide background functionality it would improve the user's experience if they didn't need to hunt for the action to explicitly launch it.
Discoverability can certainly be improved. There's a lot of redundancy between the repository list, the package list and the action list. Not sure how to best improve it. Maybe it could have some UI element to show a script that just got installed in the Action List? Or as simple as a "Run" button?
Scripts often persist state and perform other actions that will leave behind cruft when the user uninstalls the script. In Reaticulate's case, for example, it:
__startup.luaDatadirectory (which is not tracked by ReaPack as the filename changes)It's come up several times now where I wished I had the ability to add a ReaScript hook that ReaPack invokes during uninstall to take care of the above cases.
So the idea is for ReaPacks to be able to define a pre-uninstall entrypoint script that the ReaPack extension calls when the user performs the uninstall action. The hook's script would be distributed with the ReaPack, but would not necessarily be included as an action, given that we probably wouldn't want users to run this directly. ReaPack could implicitly register the script as an action, invoke it, then unregister it.
Ideally ReaPack would also wait for the script to terminate before proceeding, in case the hook script opens a gfx window that invites some user-interaction (for example to choose how thoroughly things should be cleaned up). I'm not sure if this is actually possible for extensions to detect, and I understand dealing with edge cases (such as misbehaving hook scripts) would be tedious, but it would improve the flexibility of the hook to be able to load additional content distributed with the ReaPack as part of the hook before the ReaPack extension deletes the files.
For symmetry, a post-install hook would be really nice as well. Less important than a pre-uninstall hook IMO, but It would improve UX if at installation time I could prompt the user to ask if they wanted to launch the main script right away. Not terribly useful for discrete actions of course, but for long-running scripts that provide background functionality it would improve the user's experience if they didn't need to hunt for the action to explicitly launch it.