Quote:
Originally Posted by jackie_w
I've been thinking about this for a while. Kepubify is a great option for those who prefer to avoid calibre but I really wonder whether it's a good idea to add kepubify as a calibre plugin. Isn't it likely to add unnecessary confusion to which Kobo/kepub/calibre features happen in kepubify and which happen in the KoboTouch/KoboTouchExtended drivers, or even some things being done twice. Isn't it likely to result in extra support work for both sides?
|
I have been wondering this as well. I'm on the fence on if I'm making it a UI plugin or a conversion plugin, but I'm thinking of making it a UI plugin (a button) for the following reasons:
1. No possibility of confusion. One is a kepubify button, the other is Calibre's conversion interface.
2. Easier for me to implement. No need to deal with the other Calibre conversion steps.
3. No conflicts with the existing plugin.
4. No automated conversion to cause confusion.
5. Easier to understand which the user is using.
6. Kepubify would retain control over it's conversion process.
7. No users trying to use kepubify through ebook-convert instead of the actual command line interface.
If you have any objections or suggestions/criticism with my reasoning, I'd be happy to hear it. I'm not making the plugin for myself (I don't use Calibre); I'm making it due to the many requests I have recieved.
Note that even if I don't make it a plugin, I can still add integration by allowing a user to drag a Calibre library over kepubify (which I'm working on right now, see the kepubify v3 issue on GitHub). Kepubify would detect the library and convert with a .kepub extension instead and will also convert to the correct folder.