Plugin Development

[DiapDealer]

Originally Posted by Doitsu

I've got a related question: is there a built-in property that I can use to make Sigil display the dirty-flag asterisk even when no file was changed? (I know that I can simply add and remove a dummy file, but I'm wondering if there's a more elegant method using a built-in property.)

Your method is really about as good as any, to be honest. There is no dedicated "dirty" property for the plugin framework that could be set by a user. The plugin wrapper simply has "modified", "added" and "deleted" dictionaries that are maintained so that PluginRunner knows what duties to perform whenever control is returned from the plugin to Sigil. Manually manipulating those dictionaries would be no more elegant than your suggested solution (perhaps even less so), and could potentially crash the launcher if handled incorrectly.

[DiapDealer]

Originally Posted by BeckyEbook

I need one more thing: how to detect (via the plugin) if the file has been modified but not saved (exist * after filename).

Originally Posted by DiapDealer

It's probably best to create modified flags for yourself in your plugin. Whether that's by setting flags whenever you know that your plugin has modified a file, or by gathering a list of some sort of file checksums before processing and then comparing those files checksums before exiting.

Plugins work on copies of files. Meaning changes aren't incorporated into the existing plugin until after the plugin completes.

There are some dictionaries in wrapper.py that can be accessed with that info, but that's considered bad form (somewhat) since unforeseen things can happen if those dictionary contents are accidentally modified incorrectly.

it occurs to me that I may have misunderstood your question. If you're asking if there's a way for plugins to know which of an epub's files are changed-but-unsaved before the plugin took control, I'm afraid the answer is no. Plugins simply get copies of an epub's contents in their current state. There is no regard whatsoever for whether or not the epub is in an unsaved state.

It occurs to me, however, that it may be a good idea for there to be such info passed to plugins. Maybe not at the individual file level, but I think there probably should be a way for a plugin to request/warn that an epub is in and unsaved state before continuing. I'm thinking of output/input plugins especially. With Kevin's new FolderOut plugin for instance, silently saving an OEBPS copy of an unsaved epub might cause unnecessary confusion.

[BeckyEbook]

I was referring to the case that my validation plugin should work on the saved file (offset is calculated more precisely because command "save" places the code a bit differently).
That's why I wanted to add a check before running the plugin.

If not saved:
    Show message "Save the file first"
else:
    Run

[KevinH]

A validation plugin is not an edit plugin. It simply finds and reports errors from what is inside Sigil currently, that allows the user to easily visit each error after the plugin ends.

You validation plugin gets those file contents via the launcher interface code to prevent issues. There are a variety of interface calls to get a copy of the entire epub or specific types based on iterators.

It should not be opening an external .epub file and trying to map errors inside to what is already inside Sigil.

[BeckyEbook]

Originally Posted by KevinH

A validation plugin is not an edit plugin. It simply finds and reports errors from what is inside Sigil currently, that allows the user to easily visit each error after the plugin ends.

I understand it perfectly.

Originally Posted by KevinH

You validation plugin gets those file contents via the launcher interface code to prevent issues. There are a variety of interface calls to get a copy of the entire epub or specific types based on iterators.

Sure.

Originally Posted by KevinH

It should not be opening an external .epub file and trying to map errors inside to what is already inside Sigil.

I do not want to do this.
Simply, my code is not perfect and if I knew that the epub file was saved, I would be happy with the current solution. But if it is not possible – I have to write a smarter plugin…

By the way.
I was compile my own version with support for 10 plugins. I do not have to constantly go to the menu. The icons help me to recognize the plugins without looking at the tooltip.

[KevinH]

Looks like fun! Perhaps we should allow the user to use their own icons for plugins. It is at least something to consider. Or perhaps allow each plugin author to include an icon file inside the plugin folder that is picked up by Sigil.

[DiapDealer]

Originally Posted by KevinH

Looks like fun! Perhaps we should allow the user to use their own icons for plugins. It is at least something to consider. Or perhaps allow each plugin author to include an icon file inside the plugin folder that is picked up by Sigil.

I thought about that as well. Use the default unless there's an icon file present.

[KevinH]

@DiapDealer,
We could change Sigil/src/Misc/Plugin.cpp to check for and load the icon file once on initial startup and then for the appropriate Qt action related to plugins in MainWindow use the setIcon to set the plugin's icon.

We could require a 48x48 png and look in the root of the plugin folder for a file called plugin.png.

Looks doable to me. What do you think?

Or should we require a plugin.svg file and go for vector icons?

[DiapDealer]

Vector graphics would probably scale better for all potential sizes (which can be increased/decreased by user preference for the main menu), but not being a graphics guy, I have no idea if an svg-only restriction would be a hardship or not.

[KevinH]

So let’s go with plugin.png first with 48x48 and later on we can give preference to plugin.svg if it exists.

[DiapDealer]

Works for me!

[BeckyEbook]

Again me: Validate OPF and offset.
I found the issue that bothered me.

bk.get_opf() -- is not perfect.

Why?
Result of bk.get_opf() is not current state of file .opf. This is state "what will the .opf file look like after saving" + missing two spaces before <metadata and </metadata> + missing four spaces before each <dc:… and <meta ….

These missing spaces prevented me from calculating the offsets accurately.

    opf_data = bk.get_opf()
    opf_data = re.sub("<metadata","  <metadata",opf_data)
    opf_data = re.sub("<meta ","    <meta ",opf_data)
    opf_data = re.sub("<dc:","    <dc:",opf_data)
    opf_data = re.sub("</metadata","  </metadata",opf_data)

[DiapDealer]

Originally Posted by BeckyEbook

Again me: Validate OPF and offset.
I found the issue that bothered me.

bk.get_opf() -- is not perfect.

Why?
Result of bk.get_opf() is not current state of file .opf. This is state "what will the .opf file look like after saving" + missing two spaces before <metadata and </metadata> + missing four spaces before each <dc:… and <meta ….

These missing spaces prevented me from calculating the offsets accurately.

    opf_data = bk.get_opf()
    opf_data = re.sub("<metadata","  <metadata",opf_data)
    opf_data = re.sub("<meta ","    <meta ",opf_data)
    opf_data = re.sub("<dc:","    <dc:",opf_data)
    opf_data = re.sub("</metadata","  </metadata",opf_data)

Use:

opf_data = bk.readotherfile("OEBPS/content.opf")

if you want to make sure you get the current state of the opf.

bk.get_opf() is performing some parsing/rebuilding of the various sections of the opf.

[KevinH]

The opf obtained by bk.get_opf() is built on the fly to reflect whatever changes have been done in and by the plugin so far. The same is true inside Sigil as well. The opf is always kept in machine parseable format. Things like comments and whitespace are not kept as they will be rebuilt as files are added and removed. You should only use line offsets to report errors in the opf as whitespace is meaningless.

A validator should not be modifying anything and in that case doing as DiapDealer said in his post above will give you the original opf that was present when the plugin was started. As soon as a plugin modifies something that impacts the opf, even this function will return the built on the fly version of the opf.

[BeckyEbook]

@DiapDealer. Thank you. I will try it.

Originally Posted by KevinH

You should only use line offsets to report errors in the opf as whitespace is meaningless.

A version with line offsets only was not enough for me. I wanted better