Quote:
Originally Posted by KevinH
Similarly we could create an automate-param variable at the Windows level that Plugin runner could also write to the sigil.cfg and create an plugin interface call in wrapper.py to get that value.
|
That was sort of what I was envisioning if we do anything. I was literally thinking of taking the string value of the parameter field (for a plugin step in an automation list) and writing it to sigil.cfg and making it available to a plugin via wrapper.py. After that, my idea was to leave it entirely up to the plugin dev to decide a) what can be used in the parameter field for their plugin in an automation step (if anything), and b) what to do with that parameter string in their plugin if it's present.
Quote:
Originally Posted by KevinH
So all of these things are doable but I would love to know how these parameters (outside of in-automate) would be useful.
|
The "in-automate" flag would be enough for me, for the most part, but as for why any extra parameters might be useful: I can only use my TagMechanic discussion as an example.
Several people mentioned that they use very similar parameters repetitively and would like to be able save those selections, and perhaps name them and be able to select them rather than entering them each time they run the plugin. Being able to pass the name of the settings profile they want to use in the parameter field of a plugin's automate step could allow the plugin to run without interaction. Such a string value could also be parsed (by the plugin-dev, not Sigil) for more granular control over what dialogs could be bypassed.
As I said, I don't want to get too in-depth with it. I just would be interested in the parameter string of an automation step (a step that's a plugin) being made available to the plugin via wrapper.py. The rest is up to the plugin-dev (both what goes in the parameter field, and what they do with it). The fact that the resulting wrapper.py property is not None could serve as the "in-automate" flag.
But if writing the automate step's parameter string to sigil.cfg is not feasible (or too unwieldy), I could also work with a boolean "in-automate" flag.