Quote:
Originally Posted by KevinH
I get it. You pass the name of a settings file to the plugin so that it can use that particular settings file to load needed values by the plugin.
|
Sort of, but not quite. I wouldn't be using a separate settings file that the plugin needed to have access to. The named/saved settings would be saved to the plugin's preferences and accessible through the normal plugin prefs.
Quote:
Originally Posted by KevinH
So under your approach, we would have one plugin parameter variable at a MainWindow level, that can be changed any time by a new Tool command called SetPluginParameter that accepts a single string parameter and it sets that MainWindow level variable. This variable is also cleared either after every plugin returns or when an automate list completes.
|
Actually, I wasn't planning on getting MainWindow involved (any more than it's already involved with running plugins, that is), or needing a new tool to be created.
My original thought was to use the pre-existing parameter field in the Automate List editor to enter the parameter for the plugin. Much like is done with the parameter for the RunSavedSearchReplaceAll tool. Is that not doable without reinventing a ton of wheels? Could the Automation List editor's parameter field not make its way to the sigil.cfg file (and thus wrapper.py) without a ton of work?
For those using my plugin outside of an automation list. I would simply provide an interface allowing them to choose the saved setting they wanted. I only want to provide a custom parameter to plugins when they run as a step in an automation list. Not for regular MainWindow plugin launches.
Apologies if I'm only further muddying the waters.
