Possible To-Do List for Future Sigil Releases Post Sigil 1.8 - Page 2

DiapDealer · 10-28-2021, 09:55 AM

@KevinH:

I think they're probably referring to a recent discussion in my TagMechanic plugin thread. I mentioned that there's no current way from within Sigil for custom parameters to passed to plugins via automation list runs.

I had speculated on whether it would be feasible to provide an optional argument to Sigil's plugin launcher code, that would allow the parameter field of an automated list's step to be made available to a plugin.

String only. Could be a simple as something to let the plugin know that it IS, in fact, running as part of an automation run. Could be something as complicated as a json string that a plugin could serialize. It would be up to the plugin dev to decide what goes in the parameter field, and how their plugin would use it.

All speculation though. I don't even know if it could be easily incorporated. But to be clear: the last thing I was suggesting was any kind of Sigil-compliance-based parameter syntax that all plugin-devs would need to adhere to. Just an optional string value they could use in any way they saw fit in their plugin's code--IF--they wanted their plugin to behave differently during an automation-list run.

Otherwise, I agree: Sigil was never geared toward being "fully automated". This new automation-list feature should not be seen as something that's going to continue to evolve very much. Based on the plugin included, dialogs are going to pop up, questions are going to need to be answered from time to time. We're not going to force all of our plugin devs to alter their plugin code just because someone has included it in an automation and doesn't like making a few selections.

KevinH · 10-28-2021, 11:42 AM

We could create an automate list command to write a parameter to a pluginname.cfg type file stored inside an automate folder in the Sigil Preferences folder. It would of course be up to the plugin to look there for a cfg file and to remove it once done.

But wouldn't it be easier to duplicate the plugin under a new name and each would then get their own prefs file which could be set up for specific actions.

We could also add a in-automate boolean flag to Sigil's plugin sigil.cfg and then make its value available to plugins via new wrapper.py interface call. That would probably be the easiest as in-automate is a Window level var that can be grabbed from the PluginRunner.

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.

So all of these things are doable but I would love to know how these parameters (outside of in-automate) would be useful.

Coleccionista · 10-28-2021, 11:52 AM

@KevinH

I think that's exactly it. Thanks for taking the time to repro.

DiapDealer · 10-28-2021, 12:44 PM

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.

KevinH · 10-28-2021, 01:01 PM

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?

DiapDealer · 10-28-2021, 01:39 PM

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.

KevinH · 10-28-2021, 01:48 PM

Yes that was what I as proposing. FWIW, PluginRunner gets many of its cfg values from the MainWindow that it is launched from (ie its BookBrowser, etc) so a MainWindow member variable is what the Automate Tool would need to be able to set. It would be easy to create a new AutomateList Tool command "SetPluginParameter" that accepts a single parameter whose value is used to set the MainWindow's member variable value so that PluginRunner can pick it up (empty when not set).

DiapDealer · 10-28-2021, 01:53 PM

Gotcha. I need to get more familiar with the AutomateList code so I converse more intelligently about it.

Binchen · 10-28-2021, 02:15 PM

Quote:

Originally Posted by KevinH

Exactly what would your list of key value pairs entail and how specifically (with examples) would this be helpful given the above?

That would be specific to each plugin as every plugin needs another input.

Binchen · 10-28-2021, 02:24 PM

Quote:

Originally Posted by DiapDealer

Otherwise, I agree: Sigil was never geared toward being "fully automated".

I can't accept that argument, because there was a period in the past when Sigil was never designed to run plugins. And now it can.

DiapDealer · 10-28-2021, 02:36 PM

Quote:

Originally Posted by Binchen

I can't accept that argument, because there was a period in the past when Sigil was never designed to run plugins. And now it can.

You're missing the point. There's a difference between automation and "fully automated". Nothing we do is geared toward making sure a Sigil user can do things without ever encountering decision points, or avoiding all decision dialogs, or having to make selections. Nor will what we do in the future be geared toward such a goal. Sigil is an epub editor, not an epub processing command-line tool/library.

You not accepting that argument is neither here nor there. I'm not seeking your acceptance. I'm just telling you what is. Take it or leave it.

KevinH · 10-28-2021, 03:16 PM

Completely different beast. When I designed the Sigil plugin interface it had PluginRunner as a Modal dialog, thereby suspending further Sigil actions. Basically we suspend Sigil while the plugin runs. We also designed the result xml that is passed back from the plugin so that Sigil itself could make the actual changes and not the plugin (for safety). None of this required any redesign of how Sigil works.

This is also true for the automation lists. It was designed to work that way to prevent the need for a Sigil redesign and prevent the need to develop a scripting language.

Full automation is simply not our goal nor is developing our own scripting language to replace python. As DiapDealer said Sigil is not a command line tool and library for working with epubs. It requires decisions be made, inputs provided, etc.

And as DiapDealer said, this decision is not negotiable.

KevinH

Quote:

Originally Posted by Binchen

I can't accept that argument, because there was a period in the past when Sigil was never designed to run plugins. And now it can.

KevinH · 10-28-2021, 05:15 PM

Arrgghhh! Actually, I looked at the search code and docs/tooltips and it states it will always stop at the first place a match is found.
So this behaviour is not an actual bug. Search does not keep state or remember where you start or where you have reached so you can stop / abort any search at will.

Unfortunately, if you decide to make no replacement at some point, the next time it will loop around when restarted and find that same place and never advance!

To change this would take a complete redesign of the entire "stateless" search process.

Perhaps a checkbox for every search item so you can disable it somehow manually before restarting if it stops advancing or some other way for you to temporarily skip a search easily before rerunning.

I will have to think about how this could be done without creating a problem.

Quote:

Originally Posted by Coleccionista

@KevinH

I think that's exactly it. Thanks for taking the time to repro.

Coleccionista · 10-29-2021, 04:26 AM

Quote:

Originally Posted by KevinH

Arrgghhh! Actually, I looked at the search code and docs/tooltips and it states it will always stop at the first place a match is found.
So this behaviour is not an actual bug. Search does not keep state or remember where you start or where you have reached so you can stop / abort any search at will.

So "By design" then

I hoped for "Find Next" to jump to the next expression but it won't move on to a new search as long as the current search loaded still returns any match.
What can I say? Do what you think it's best. It's your time after all.

democrite · 12-15-2021, 02:32 AM

One thing I'm not sure if I've brought up. Would it someday be possible to preserve modification dates within the EPUB, e.g. if a file hasn't been modified, keep the old date? Such may be hard to keep track of, I don't know. I'm not sure if I am the only one, looking at the mod dates within the epub/zip helps me know if I made any accidental changes to any file as well as knowing the last mod date of a particular chapter or section.

10-28-2021, 09:55 AM	#16
DiapDealer Grand Sorcerer Posts: 27,552 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	@KevinH: I think they're probably referring to a recent discussion in my TagMechanic plugin thread. I mentioned that there's no current way from within Sigil for custom parameters to passed to plugins via automation list runs. I had speculated on whether it would be feasible to provide an optional argument to Sigil's plugin launcher code, that would allow the parameter field of an automated list's step to be made available to a plugin. String only. Could be a simple as something to let the plugin know that it IS, in fact, running as part of an automation run. Could be something as complicated as a json string that a plugin could serialize. It would be up to the plugin dev to decide what goes in the parameter field, and how their plugin would use it. All speculation though. I don't even know if it could be easily incorporated. But to be clear: the last thing I was suggesting was any kind of Sigil-compliance-based parameter syntax that all plugin-devs would need to adhere to. Just an optional string value they could use in any way they saw fit in their plugin's code--IF--they wanted their plugin to behave differently during an automation-list run. Otherwise, I agree: Sigil was never geared toward being "fully automated". This new automation-list feature should not be seen as something that's going to continue to evolve very much. Based on the plugin included, dialogs are going to pop up, questions are going to need to be answered from time to time. We're not going to force all of our plugin devs to alter their plugin code just because someone has included it in an automation and doesn't like making a few selections. Last edited by DiapDealer; 10-28-2021 at 10:50 AM.

10-28-2021, 01:01 PM	#20
KevinH Sigil Developer Posts: 7,654 Karma: 5433388 Join Date: Nov 2009 Device: many	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? Last edited by KevinH; 10-28-2021 at 01:05 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New Policy on Translations Included with Sigil Releases	KevinH	Sigil	0	03-08-2019 10:37 AM
Icon Redesign for future 1.0 Release of Sigil	shorshe	Sigil	38	06-06-2016 11:29 PM
Sigil on Nook vs Sigil on Kobo vs Sigil on iBook	rosshalde	Sigil	12	11-13-2014 09:34 AM
Sigil’s Future Direction (Post 0.4.x)	user_none	Sigil	90	10-11-2011 03:28 PM
Sigil's Future	crutledge	Sigil	36	07-26-2011 06:02 PM

10-28-2021, 11:42 AM	#17
KevinH Sigil Developer Posts: 7,654 Karma: 5433388 Join Date: Nov 2009 Device: many	We could create an automate list command to write a parameter to a pluginname.cfg type file stored inside an automate folder in the Sigil Preferences folder. It would of course be up to the plugin to look there for a cfg file and to remove it once done. But wouldn't it be easier to duplicate the plugin under a new name and each would then get their own prefs file which could be set up for specific actions. We could also add a in-automate boolean flag to Sigil's plugin sigil.cfg and then make its value available to plugins via new wrapper.py interface call. That would probably be the easiest as in-automate is a Window level var that can be grabbed from the PluginRunner. 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. So all of these things are doable but I would love to know how these parameters (outside of in-automate) would be useful.

10-28-2021, 11:52 AM	#18
Coleccionista Connoisseur Posts: 67 Karma: 40 Join Date: Aug 2010 Device: iPad, Kindle Paperwhite	@KevinH I think that's exactly it. Thanks for taking the time to repro.

10-28-2021, 01:48 PM	#22
KevinH Sigil Developer Posts: 7,654 Karma: 5433388 Join Date: Nov 2009 Device: many	Yes that was what I as proposing. FWIW, PluginRunner gets many of its cfg values from the MainWindow that it is launched from (ie its BookBrowser, etc) so a MainWindow member variable is what the Automate Tool would need to be able to set. It would be easy to create a new AutomateList Tool command "SetPluginParameter" that accepts a single parameter whose value is used to set the MainWindow's member variable value so that PluginRunner can pick it up (empty when not set).

10-28-2021, 01:53 PM	#23
DiapDealer Grand Sorcerer Posts: 27,552 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Gotcha. I need to get more familiar with the AutomateList code so I converse more intelligently about it.

12-15-2021, 02:32 AM	#30
democrite Evangelist Posts: 425 Karma: 77256 Join Date: Sep 2011 Device: none	One thing I'm not sure if I've brought up. Would it someday be possible to preserve modification dates within the EPUB, e.g. if a file hasn't been modified, keep the old date? Such may be hard to keep track of, I don't know. I'm not sure if I am the only one, looking at the mod dates within the epub/zip helps me know if I made any accidental changes to any file as well as knowing the last mod date of a particular chapter or section.

Advert

Advert