Plugin Development

[KevinH]

Hi rubeus,

Yes, there is a bug in the wrapper.py but only for appending to the very end of the spine. Luckily there is a workaround using the other interface routines until we fix this in the next release.

Please try the following:

    uid = 'T12345' 
    bk.addfile(uid, 'Test0001.xhtml', xml, 'application/xhtml+xml')
    new_spine = bk.getspine()
    new_spine.append((uid, None))
    bk.setspine(new_spine)

Please let me know if that does the trick.

The spine_insert_before call does work for prepending to the spine and putting it in the middle someplace, but just not for appending to the end. I have already fixed this in master for the next release.

Thanks for the bug report!

KevinH

[rubeus]

The workaround is doing fine, thx for that.

[Doitsu]

Originally Posted by KevinH

This is a head's up for all plugin developers. In my dev tree I have made changes to support the following new plugin.xml tag.

<autostart>true</autostart>

I've tested it and it works great.



Would it be possible to also completely hide the Plugin Runner dialog box for autostart & autoclose plugins (e.g validation plugins) or maybe display a generic Qt progress bar/sand timer/spinner instead?

[KevinH]

Hi Doitsu,
That would require a bit more work and a redesigned PluginRunner Dialog. The user also needs access to a Cancel button if the plugin hangs at all. So for now, you will have to live with the console, progress bar, and cancel button.

Maybe in the future I will try to hide the Start button and console parts,but that is not a priority given the current dialog works for both right now. Perhaps, we could add a "Show Details..." button to hide and show the console output. I will look into it when I get some free time.

KevinH

Originally Posted by Doitsu

I've tested it and it works great.



Would it be possible to also completely hide the Plugin Runner dialog box for autostart & autoclose plugins (e.g validation plugins) or maybe display a generic Qt progress bar/sand timer/spinner instead?

[rubeus]

Another option in the xml shrinking the plugin runner window to a minimum?

[rubeus]

How do i determine the mimetype of an image file? The magic lib is not installed in the built in python. I had a look at PIL but only found im.format which seems to be more reliable than the extension, but still needs conversion to a mimetype. How is Sigil doing that adding an image file?

//rubeus

[KevinH]

In python you can import imghdr to find out what type of image a data file is and then use a file type extension lookup in a dictionary (hash table)

Here is an piece of the OPFResource.cpp file:

// Initializes m_Mimetypes
void OPFResource::CreateMimetypes()
{
    m_Mimetypes[ "jpg"   ] = "image/jpeg";
    m_Mimetypes[ "jpeg"  ] = "image/jpeg";
    m_Mimetypes[ "png"   ] = "image/png";
    m_Mimetypes[ "gif"   ] = "image/gif";
    m_Mimetypes[ "tif"   ] = "image/tiff";
    m_Mimetypes[ "tiff"  ] = "image/tiff";
    m_Mimetypes[ "bm"    ] = "image/bmp";
    m_Mimetypes[ "bmp"   ] = "image/bmp";
    m_Mimetypes[ "svg"   ] = "image/svg+xml";
    m_Mimetypes[ "ncx"   ] = NCX_MIMETYPE;
    // We convert all HTML document types to XHTML
    m_Mimetypes[ "xml"   ] = "application/xhtml+xml";
    // m_Mimetypes[ "xml"   ] = "application/oebs-page-map+xml";
    m_Mimetypes[ "xhtml" ] = "application/xhtml+xml";
    m_Mimetypes[ "html"  ] = "application/xhtml+xml";
    m_Mimetypes[ "htm"   ] = "application/xhtml+xml";
    m_Mimetypes[ "css"   ] = "text/css";
    m_Mimetypes[ "mp3"   ] = "audio/mpeg";
    m_Mimetypes[ "oga"   ] = "audio/ogg";
    m_Mimetypes[ "ogg"   ] = "audio/ogg";
    m_Mimetypes[ "mp4"   ] = "video/mp4";
    m_Mimetypes[ "ogv"   ] = "video/ogg";
    m_Mimetypes[ "webm"  ] = "video/webm";
    m_Mimetypes[ "smil"  ] = "application/smil+xml";
    m_Mimetypes[ "pls"   ] = "application/pls+xml";
    m_Mimetypes[ "js"    ] = "text/javascript";
    // Until the standards gods grace us with font mimetypes,
    // these will have to do
    m_Mimetypes[ "otf"   ] = "application/vnd.ms-opentype";
    m_Mimetypes[ "ttf"   ] = "application/x-font-ttf";
    m_Mimetypes[ "ttc"   ] = "application/x-font-truetype-collection";
    m_Mimetypes[ "woff"  ] = "application/font-woff";
}

Here is a similar piece of python code used by the launcher:

ext_mime_map = {
                '.jpg'  : 'image/jpeg',
                '.jpeg' : 'image/jpeg',
                '.png'  : 'image/png',
                '.gif'  : 'image/gif',
                '.svg'  : 'image/svg+xml',
                '.xhtml': 'application/xhtml+xml',
                '.html' : 'application/xhtml+xml',
                '.ttf'  : 'application/x-font-ttf',
                '.otf'  : 'application/x-font-opentype',
                '.woff' : 'application/font-woff',
                '.mp3'  : 'audio/mpeg',
                '.mp4'  : 'video/mp4',
                '.css'  : 'text/css',
                '.ncx'  : 'application/x-dtbncx+xml',
                '.xml'  : 'application/oebs-page-map+xml',
                '.opf'  : 'application/oebps-package+xml',
                '.smil' : 'application/smil+xml',
                '.pls'  : 'application/pls-xml',
                '.js'   : 'text/javascript',
                '.epub' : 'application/epub+zip',
                #'.js'   : 'application/javascript',
                #'.otf'  : 'application/vnd.ms-opentype',
                }

You can find exmples of how to use imghdr in the KindleUnpack mobi_cover.py link I sent to you. That piece of python code does the same thing.

[Doitsu]

Originally Posted by rubeus

How do i determine the mimetype of an image file?

You can also use the imghdr package. (I used it in the PasteImage plugin.)

[KevinH]

Hi Doitsu,

Originally Posted by Doitsu

Would it be possible to also completely hide the Plugin Runner dialog box for autostart & autoclose plugins (e.g validation plugins) or maybe display a generic Qt progress bar/sand timer/spinner instead?

I have thought some more on this but the need to have a Cancel button for hanging plugins and the need to have a modal Dialog makes having something there necessary.

What I have done with the very latest commits today:

If and only if a plugin.xml sets both autostart and autoclose to "true"
then the Plugin Dialog is greatly shrunk in size with just the progress bar, Cancel button, and a new "Details..." button beside the "Okay" button. The Console widget is hidden completely. This dialog will disappear upon a successful return of the plugin.

If on the other hand the plugin takes too long to run (hanging?) or it fails (returns a nonzero value) the user can hit the "Details..." button to grow the dialog and show the Console itself. If the Console widget shows no progress, the user can always hit the Cancel button to terminate things or simply copy any error message out of the console window to report the error to the plugin developer.

So if you get a free moment, please rebuild from master today, and then edit one of your plugin's plugin.xml to have both of these:

<autostart>true</autostart>
<autoclose>true</autoclose>

Then modify the that plugin's plugin.py file to return 1 not 0 (ie. tell Sigil the plugin failed).

You will let your plugin "fail" so you get a chance to see the smaller dialog and hit the Details... button if you so desire. Otherwise it may flash by too fast to see it.

Please let me know if you think this is an improvement or not.

KevinH

[rubeus]

Originally Posted by KevinH

Please let me know if you think this is an improvement or not.

From myside. a big step forwad bringing the plugins closer to the end user and still being separated from sigil enough to not destabilize sigil itself if the plugin is running wild

[KevinH]

Hi All,

FYI,

Earlier in this thread, we have now posted the Mapping of Sigil Version to Plugin Launcher Version information for all 0.8.X and later releases. We have also added information on specific plugin related changes for each of the Sigil-0.9.X pre-releases and releases.

The launcher_version always returns a simple integer representing the date YYYYMMDD when the final change to the launcher code was made for the upcoming release.

If your plugin requires a specific version of Sigil, you should be able to use this information to determine your minimum supported Sigil version (at least in the Sigil-0.9.X series).

See this post for more information:

https://www.mobileread.com/forums/sho...07&postcount=3

[KevinH]

Hi rubeus,

Thanks for that feedback. Given Sigil plugins really do run in a completely separate process (forked from Sigil's process) and the only interaction is via sharing files in a temp directory and returning xml, a Sigil plugin will never be "close to the user" no matter how much we change the GUI.

The whole interface was designed from scratch to isolate Sigil from any plugin as much as could be done to prevent a plugin crash from bringing down Sigil in any way.

Take care,

KevinH

Originally Posted by rubeus

From myside. a big step forwad bringing the plugins closer to the end user and still being separated from sigil enough to not destabilize sigil itself if the plugin is running wild

[rubeus]

Well from an end user point of view i still believe that its nearer to the end user even if it only seems to be. End users do only have the view from UI point of view and are not interested in technical details. If you make this more smoother its closer without doubt. You just need to change your developer point of view and the knowledge you have about internas. End users do not have your knowledge and the more (technical) details you hide from them makes plugins more integrated, even if it isnt like that

[Doitsu]

Hi KevinH,

Thanks for considering my suggestions. I really appreciate it.

Originally Posted by KevinH

So if you get a free moment, please rebuild from master today, and then edit one of your plugin's plugin.xml to have both of these:

I grabbed the latest files and created a new build at around 19:20 UTC. Unfortunately, I wasn't able to test your additions, because returning -1 via plugin.py didn't trigger an error message and didn't stop the autoclose.

Unless I made yet another stupid beginner's mistake, it looks like the plugin runner code ignores a return value of -1. (It also had no effect in the official 9.2 Windows release.)

Apparently, I did not grab the latest files from Github.

[KevinH]

Hi Doitsu,
That is strange and I am not seeing that in my build. There were earlier changes to the launcher.py that fixed the handling of the return values. This would only exist in master, not Sigil-0.9.2.

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

https://github.com/Sigil-Ebook/Sigil...a39683a5d1078f

Thanks,
KevinH