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

I effectively do that now in my automate lists by duplicating and renaming the duplicate plugin so that it reads from its own settings file.

For example, assume your TagMechanic plugin has 3 different settings files for 3 different repetitive actions called doit1, doit2, and doit3, then I create 3 different TagMechanic plugin copies called TagMechanic-doit1, TagMechanic-doit2, and TagMechanic-doit3 and load them all into Sigil and invoke them in any automate list (I actually do this with one of my horribly written rough cleanup plugins that did not have a gui anyway). But your approach is cleaner.

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.

In PluginRunner, it will add that value into the sigil.cfg file and pass it to the plugin launcher/wrapper code. We add a call to wrapper.py and the various container classes to return that value as a unicode string, called something like bk.get_plugin_parameter() or whatnot.

How does that sound?