[Plugin] KindleImport Sigil plugin

[KevinH]

Hi,

No, that is not correct. Putting a valid epub into kindlegen is your best bet. Use "id" and not "name". That guidelines example is old and should be updated. The point they were trying to make is that the anchor must come before the tag, in order for internal links to be processed correctly by Amazon software, they were not endorsing "name".

KevinH

[DiapDealer]

And besides that ... @NotJohn's point about name vs id isn't really relevant to begin with. KindleUnpack/KindleImport doesn't really care. If "name" went in, "name" comes out. Others were hinting that the KindleImport plugin should "fix" things like "name." I've taken the stance that KindleImport is going to provide an "I opened it in Sigil, now it's your turn" service.

[JSWolf]

Is this plugin going to be updated with the latest code from KindleUnpack 0.77?

[eschwartz]

Originally Posted by JSWolf

Is this plugin going to be updated with the latest code from KindleUnpack 0.77?

Ah, such patience! You are an example to us all.

[JSWolf]

Originally Posted by eschwartz

Ah, such patience! You are an example to us all.

I'm just asking if this is going to happen. I'm not asking for it now. Your way of reading things that don't exist is astounding.

[eschwartz]

Originally Posted by JSWolf

I'm just asking if this is going to happen. I'm not asking for it now. Your way of reading things that don't exist is astounding.

I am sure it will, just like the calibre plugin was.

[DiapDealer]

Originally Posted by JSWolf

Is this plugin going to be updated with the latest code from KindleUnpack 0.77?

Yep. I knew I was forgetting something.

[varlog]

Hi,
using the plugin (with my preserve_file_name.patch) I noticed that for some files the name proposed is, instead of original file name, the title of the book. How unorderly . Before I go looking (python ) for the guilty could you explain/point me?

[varlog]

Originally Posted by JSWolf

Is this plugin going to be updated with the latest code from KindleUnpack 0.77?

This is what I miss by current plugin architecture - it should be possible just to drop in the new library.

[DiapDealer]

Originally Posted by varlog

This is what I miss by current plugin architecture - it should be possible just to drop in the new library.

It still IS possible. There's nothing stopping anyone from extracting the plugin's contents, plopping in the 0.77 files and zipping it all back up and installing. Or better yet, just drop the core 0.77 files in the plugin's kindleunpack folder in the user directory where plugins are installed. Easy-peasy.

[varlog]

Originally Posted by DiapDealer

It still IS possible. There's nothing stopping anyone from extracting the plugin's contents, plopping in the 0.77 files and zipping it all back up and installing. Or better yet, just drop the core 0.77 files in the plugin's kindleunpack folder in the user directory where plugins are installed. Easy-peasy.

For some of us perhaps... if we take time for it... For the rest of users there should be a menu "Update Library" somewhere.
But at the moment I'm rather more interested in this.

[DiapDealer]

Originally Posted by varlog

For some of us perhaps... if we take time for it... For the rest of users there should be a menu "Update Library" somewhere.

Well that's something completely different than what Jon was referring to. What sort of plugin architecture is going to accommodate automatically updating only portions of a plugin's (any number of plugins, actually) code? Perhaps you're referring to the launcher code itself? Hell, even that wouldn't be that difficult to implement an update feature, or install package to update that code without a full Sigil release. It's early days yet--and the architecture is flexible. After functionality gets rolling, the bells and whistles can be added.

But at the moment I'm rather more interested in this.

Any file names coming out of KindleImport other than "untitled," or "new," or "book" probably shouldn't be depended upon. I'm not going to spend a lot of time/effort/resources creating (and sanitizing) meaningful file names that are never going to be seen by the vast amount of users. I understand you have some Sigil patches that make use of some of the output of my earlier versions of the plugin, but I honestly haven't even thought about those file naming routines since the current official Sigil release guarantees "untitled.epub" as the end result of an import plugin for Sigil's titlebar and Save As dialog.

If you're using v0.1.1beta, the differences in the filenames you're experiencing are probably dependent on whether or not the file is a mobi-only ebook or a KF8 ebook. I had worked on getting the Updated Title from the OPF metadata (the makeEpub method in quickepub.py) and returning a sanitized version of that for the epub name before I lost interest (and Sigil's codebase made the file name pointless). A KF8 book was returning a name based on the ebook's original file name (unpackEPUB in mobi_stuff.py).

You should hang on to v0.1.1beta if those routines hold any interest for you. I won't guarantee they'll survive all that much longer.

[varlog]

Originally Posted by DiapDealer

Well that's something completely different than what Jon was referring to. What sort of plugin architecture is going to accommodate automatically updating only portions of a plugin's (any number of plugins, actually) code? Perhaps you're referring to the launcher code itself? Hell, even that wouldn't be that difficult to implement an update feature, or install package to update that code without a full Sigil release. It's early days yet--and the architecture is flexible. After functionality gets rolling, the bells and whistles can be added.

In my opinion, if the plugin uses independently developed piece of software, it should be written as a wrapper around this software - thus making a library of it. Than it is possible to update only library, only wrapper or both of them.
As the library alone wouldn't be a proper Sigil plugin, the architecture should be able to provide extra functionality for it - in this case somehow adding it, in Sigil-plugin context, to normal python libraries.

If you're using v0.1.1beta, the differences in the filenames you're experiencing are probably dependent on whether or not the file is a mobi-only ebook or a KF8 ebook. I had worked on getting the Updated Title from the OPF metadata (the makeEpub method in quickepub.py) and returning a sanitized version of that for the epub name before I lost interest (and Sigil's codebase made the file name pointless). A KF8 book was returning a name based on the ebook's original file name (unpackEPUB in mobi_stuff.py).

Thanks.

[DiapDealer]

Originally Posted by varlog

In my opinion, if the plugin uses independently developed piece of software, it should be written as a wrapper around this software - thus making a library of it. Than it is possible to update only library, only wrapper or both of them.

That is exactly how the current KindleImport is designed. It is a wrapper around the KindleUnpack command-line tools. It doesn't have a way to automatically update just the KindleUnpack "library" files, but then again, it's early days. A tool to update just the KindleUnpack "library" isn't out of the question.

Honestly, I'm not quite sure what your point is here. The plugin is written in a way you've just indicated you think such plugins should be written (a wrapper around a "library") ... and there's absolutely nothing stopping any plugin developer from creating the update function function you desire.

[varlog]

Originally Posted by DiapDealer

That is exactly how the current KindleImport is designed. It is a wrapper around the KindleUnpack command-line tools.

I didn't know that, haven't looked in, sorry.

Honestly, I'm not quite sure what your point is here. The plugin is written in a way you've just indicated you think such plugins should be written (a wrapper around a "library") ... and there's absolutely nothing stopping any plugin developer from creating the update function function you desire.

This is not my point and I don't propose plugin updating itself.
I only mean if it were a "proper" library other plugins would be able to use it.