Plugin Development

[eschwartz]

Same here, it works fine.

Are you sure you are testing sigil 0.9.2.r12.ga63067f?

[Doitsu]

Originally Posted by KevinH

Do you also have the following changes to launcher.py in your tree. See the end of the commit diff.

I don't have these changes, I guess I must have made a mistake getting the latest source files from Github.
I'll grab them again, create a new a build and report back.

EDIT: It's working now. I've attached a screenshot of the new plugin runner dialog box.

(If you click Details, it'll display the usual Plugin Runner dialog box.)

[rubeus]

Hi,

can i get the current active/marked xhtml file in the tree to insert a file with a plugin direct behind it?

//rubeus

[KevinH]

If the user has highlighted a file name in the BookBrowser window before launching your plugin, then your plugin can get the name of that file (in fact a list of all highlighted files), and it can use that info any way you want.

See the bk.selected_iter() function in the latest Plugin Framework Guide

KevinH

Originally Posted by rubeus

Hi,

can i get the current active/marked xhtml file in the tree to insert a file with a plugin direct behind it?

//rubeus

[KevinH]

Hi All,

This is just to provide a head's up. Recent work, that will probably make it into the next release, has made epub3 editing in Sigil much more of an equal partner (at least for simple epub3 ebooks that stick to epub2 main features but done in html5).

Users will be provided with a new "General Settings" Preference window where they can set what epub version that would like all new documents to start with.

That means Mend(), splitting Files, adding existing files, index generation, ncx generation, and basic xhtml editing are now epub version aware and should not break epub3 ebooks by using the wrong doctypes and things. Also a new "Epub 3 Tools" submenu under Tools will be provided with epub3 specific tools such as "Updating Manifest Properties", and "Nav Generator".

For plugin Developers, that means starting with the next release, if your plugin was only designed to work with one type of epub due to assumptions about DOCTYPES or use of named entities and the like (epub3 only allows numeric entities) - you will need to be able to get the epub version of the ebook your plugin has been passed easily.

So we have added a new interface:

bk.epub_version()

It will return a unicode string indicating the package version attribute of the ebook being worked on by your plugin - typically returning "2.0" or "3.0".

For example, the epub3-itizer is designed to work only with valid epub2 ebooks. So my next version of the plugin will check for the required epub version and error out with a message if passed in an epub3.

The snippet of code to do that is provided as follows:

epubversion = "2.0"
if bk.launcher_version() >= 20160102:
    epubversion = bk.epub_version()

if epubversion.startswith("3"):
    print("Error: ePub3-itizer requires a valid Epub 2.0 ebook as input")
    return -1

So please look at your plugin code and see if it makes any assumptions or uses DOCTYPES and things that are epub 2 only. If so, consider either erroring out with a message similar to the code snippet above, or better yet ... us the bk.epub_version() call to properly set DOCTYPES, convert named entities to numeric entities, and things like that so that your plugin will work under both epub2 and epub3 ebooks without introducing any breakage.


Comments and questions welcome ...

KevinH

ps. If launcher_version < 20160102, it is safe to assume that you plugin has been passed an epub2 ebook for all intents and purposes.

pps. If people would like to see one approach to converted named entities to numeric entities, please check out the epub3-itizer code base which handles that.

[rubeus]

Running one of my plugins i noticed the plugin runner window was flickering a little bit. I was able to do a screen recording and captured this:



This is disappearing very fast. Am i doing something wrong or is there any way to fix this?

//rubeus

[DiapDealer]

Fix what?

[rubeus]

That this message isn't displayed

[KevinH]

Depending on your version of Sigil, you should make sure you return a non-zero value to ensure the error log is shown (things written to stderr).

Also make sure you have not enabled the "autoclose" in the plugin.xml if you are using a build from master. If this is in a validation plugin, then reporting no errors will allow it to autoclose.

You are also seeing the result xml being sent back from the launcher.py code in the plugin framework back to Sigil. I am not sure how you are seeing this? What exact version of Sigil are you using?

KevinH

[DiapDealer]

Originally Posted by KevinH

I am not sure how you are seeing this? What exact version of Sigil are you using?

I see it on very slow machines sometimes, but it still goes away pretty quickly. I think he's recorded the screen and slowed it down to capture it. I'm just not sure why. The xml message being sent back to Sigil is not for user consumption.

[KevinH]

I will look into PluginRunner.cpp to see if there is a way to prevent the result xml from being seen at all.

KevinH

[rubeus]

Hi,

i was capturing it cause it was unreadable. And what would you assume if you are testing a plugin producing output disappearing so fast it cant be read. Isnt it so far away to assume an erro in your plugin you wanna tear down? I had a look at it cause it was presented to me. And would an enduser thinks starting the plugin being aware of the same? Is it so hard to think about he might believe that the plugin went wrong and destroyed the epub. I'm tired reading those assumptions. They can only come from a developer not be able to change gus point of view. I think i need to take some break when asking here and getting such a response: Hey dude, this message isn't for you! Don't look at it!

By the way, a quadcore with 2.5 Ghz having nothing to do isnt really slow.....

@Kevin: When updateing a file with bk.writefile(id, soup.serialize_xhtml()) the screen with my messages disappears, then for a tenth of a second or may be two the xmls is presented. If you do this in loop writing back a lot of files the plugin launcher window starts to flicker. In my first assumption i thought this came from sigil_bs4 or PIL using the libs in a wrong way so i did a screen recording to find out what these messages are about.

[KevinH]

Hi rubeus,
I have never ever seen it on my Mac. Therefore, I did not know a user could ever see the result.xml file on screen (even briefly). You should always clearly see your output you wrote to stdout in the plugin and nothing else.

In other words, your "Scanning Text/coverpage.xhtml..." line with a status of Success should stay their until you close the dialog.

If your plugin returned an error or threw an uncaught exception, that screen would stay to help the plugin developer and Sigil developers to know what is wrong.

Right now, the Sigil console window shows everything written to stdout and stderror being sent back from the python process running the plugin. We do this in case of a hang or infinite loop.

Once it completes, the console window is reset to just stdout. In the brief instant before being reset you are seeing the result.xml file that Sigil uses to safely merge your changes back into the official directory holding the ebook being worked on.

I will modify the code to strip out any result.xml info but you still might see the console screen flicker once when it resets to show only stdout on success. That was how it was designed to work anyway, I had no idea the result.xml could ever be seen.

KevinH

Originally Posted by rubeus

Hi,

i was capturing it cause it was unreadable. And what would you assume if you are testing a plugin producing output disappearing so fast it cant be read. Isnt it so far away to assume an erro in your plugin you wanna tear down? I had a look at it cause it was presented to me. And would an enduser thinks starting the plugin being aware of the same? Is it so hard to think about he might believe that the plugin went wrong and destroyed the epub. I'm tired reading those assumptions. They can only come from a developer not be able to change gus point of view. I think i need to take some break when asking here and getting such a response: Hey dude, this message isn't for you! Don't look at it!

By the way, a quadcore with 2.5 Ghz having nothing to do isnt really slow.....

@Kevin: When updateing a file with bk.writefile(id, soup.serialize_xhtml()) the screen with my messages disappears, then for a tenth of a second or may be two the xmls is presented. If you do this in loop writing back a lot of files the plugin launcher window starts to flicker. In my first assumption i thought this came from sigil_bs4 or PIL using the libs in a wrong way so i did a screen recording to find out what these messages are about.

[KevinH]

Hi rubeus,
A fix is not easy. It seems the Plugin runner console window is updated asynchronously as the python plugin process outputs data. So it can be updated in small sets of bytes at a time. That makes looking for the xml result header to start stripping it out hard to do as it may come in as many different much smaller seemingly randomly generated pieces.

I will have to redesign the launcher code completely to do line buffering instead of asynchronous buffering so that I can search for the result xml info to strip it out before showing to the screen.

I will add it to my to-do list but right now there are other things higher priority.

Thanks for your bug report.

KevinH

[rubeus]

Thats fine with me. So i know where it comes from now and its not my fault nor something from one of libs i used in the plugin.