How to make Sigil live

[Hitch]

Originally Posted by Katsunami

What does it matter, if functionality similar to Sigil's will end up in Calibre, and that it is not a seperate program? You can just create a "Workspace" library, import you texts in there, and open them in the editor. Then work with them as you would with Sigil itself. Instead of opening the file from your desktop, you'd open it from your workplace library.

Assuming that somebody decides to step up and do all the heavy lifting on the editor, and it works as you've described.

It's the same approach as Lightroom takes for pictures, and it works very well there. There are a lot of people who use Lightroom as a library only, as a photo editor only, or both, myself included. There is no reason that Calibre cannot be used in the same way.

I'm not familiar with Lightroom. Can't speak to that.

While I understand the apprehension against this approach (it does yield some sort of "hybrid" program, half of which is not useful for the task you intend to do), there are also a lot of advantages. Any improvement in Calibre's EPUB2 / EPUB3 support will automatically be available in the editor (or with relatively little changes) as it uses the same input/output plugins. Any improvement in a function in Calibre that impacts the editor in some way, such as metadata editing, will automatically be an improvement in the editor. Coding in Python will be much faster and much more productive than in C++, yielding much faster bugfixes and more rapid implementation of requested functionality.

This is all theoretical. Again, I'm not particularly trying to be negative, but Kovid's userbase has different goals than I do, myself. Many of the Calibre users are making books for themselves, or converting/cleaning PD books, or...well, other stuff. I'm not saying that what they're doing is "bad" or not as important, or any other spin; I'm simply saying, my prognostications as to the direction that a Sigil-add-in will take, for Calibre users, is likely to be different than the direction I'd go, assuming arguendo I had those type of resources. I mean, hell, I could be completely wrong, but....I'm pretty sure that somewhere around here, if I looked hard enough, I could find an archived post from me saying "sometime within 2 years, we'll be looking for a new maintainer..." and here we are. (NO reflection whatsoever on User_none, who has gone above and beyond the call of duty; Sigil is an amazing product today, compared to what it was when he took over. AH-MAZING.)

I think that the chances of a calibre-hosted editor catching up with Sigil, and eventually overtaking it at some point are MUCH better than finding someone willing to look into EPUB2/EPUB3 coding, the BOOST library, QT in C++, and so on, just to maintain and extend a seperate program for a very small niche of people.

I wouldn't disagree with that statement. I think I've said much the same in my prior posts either on this thread or the other--don't remember which. There's always going to be a larger market for a product like Calibre than a product like Sigil, that's a given.

Hitch

[varlog]

There is a nice article about Calibre on lwn. I personally like Calibre very much - through Calibre somehow I've learned about Sigil and started to use it !
I guess it's just something like a question about your favourite colour: I don't know what's mine but I choose green every time. What's yours?
Quoting myself:

Qt itself has a add-a-plugin ability - see "The Lower-Level API: Extending Qt Applications". I am sure the developer/s know it and have already considered it in the past and have perfect reasons for not implementing it. I suppose one of the reasons is amount of work involved. What I would like to know are the other reasons, if any, which are perhaps obvious when one knows insides of Qt and Sigil - but not to outsider like me.

@user_none: I would really really appreciate some response... please?

[Katsunami]

Originally Posted by Hitch

This is all theoretical. Again, I'm not particularly trying to be negative, but Kovid's userbase has different goals than I do, myself. Many of the Calibre users are making books for themselves, or converting/cleaning PD books, or...well, other stuff. I'm not saying that what they're doing is "bad" or not as important, or any other spin; I'm simply saying, my prognostications as to the direction that a Sigil-add-in will take, for Calibre users, is likely to be different than the direction I'd go, assuming arguendo I had those type of resources.

You seem to be afraid that a Sigil-like editor, hosted within Calibre, can never be a Sigil replacement because it's not a standalone program. You seem to assume that such an editor will always be second citizen to the "main" program Calibre. I think this fear is unnecessary, assuming this re-implementation is done right.

I'll explain what I meant by mentioning Adobe Lightroom. This program, together with another one called RAWShooter, had the same kind of merger we're discussing here, but in the world of photography instead of e-books.

Lightroom started out as a catalogue program with limited editing capabilities; it could be seen as the "photo version" of Calibre. RAWShooter started out with powerful editing capabilities, but no catalogue options. It could be seen as the "photo version" of Sigil.

Adobe bought RAWShooter, and used part of its editing core, and many of its idea's with regard to workflow, in Lightroom. While both Lightroom and RAWShooter people were apprehensive at first (Lightroom being a powerful cataloguer, RAWShooter a powerful editor, miles apart in usage and capabilities), fearing to see "their" program become the neglected part of the merger, that fear proved unwarranted. Lightroom is now one of the top programs in te photography world, for amateurs AND professionals.

Many people use Lightroom as a catalogue program only: importing their images, and setting an external RAW-editor as editor. Many other people use Lightroom as an editor only: importing pictures into a working library, editing them in the editor, and exporting them to another catalogue program when done. Most however, import the pictures into a working library, sort/tag/weed them there, do the required edits in the editor, and then move the finished pictures to a main library, all within the same program.

I've been using Lightroom since 2008, and used RAWShooter before. Let me tell you, Lightroom's editing module is no less powerful than RAWShooter was. There is no reason that an editing module in Sigil has to be less powerful than Sigil itself, but it may take some time to get there. Until that time, you can use Sigil itself.

Therefore, I think a Calibre+Sigil merger can become for e-books what Lightroom+RAWShooter became for photography.

[Hitch]

Hi, Katsunami:

You seem to be afraid that a Sigil-like editor, hosted within Calibre, can never be a Sigil replacement because it's not a standalone program. You seem to assume that such an editor will always be second citizen to the "main" program Calibre. I think this fear is unnecessary, assuming this re-implementation is done right.

Yes. I think that the main user-base for Calibre wants a one-stop shop, for conversion purposes. We see it in here all the time, people who come into the Sigil forums asking questions, not because it has sweet <insert whatever here> to do with Sigil, but because they don't know HTML or CSS or anything at all. That doesn't make them bad people; but that's not the fundamental Sigil userbase.

I just think it's perfectly reasonable to assume that Kovid and the Calibre donors will support what the vast majority of Calibre users WANT. I think that things needed/wanted by the teeny minority of fundamental Sigil users will a) fall to the bottom of the list, simply due to prioritization versus how many folks want X versus Y, and b) not get implemented if they are something to do with the "more tecchie" aspects of Sigil, because again, what (the vast majority of) Calibre users want is almost the exact opposite of what Sigil IS.

I'm going to bow out of this discussion, because I think my input is neither fruitful nor helpful. And, we are still awaiting an editor to step up, are we not? So there's no point in fighting over a bone that does not yet exist; and I certainly wouldn't begrudge those of you that are more "Calibre-prone" a version of Sigil, or some portion thereof, that runs via Calibre. {shrug}. This discussion--or my viewpoint of it--is not helping the issue at hand.

Respectfully,
Hitch

[Katsunami]

Even if you prove to be correct, and a Calibre-hosted successor to Sigil IS on the bottom of the maintenance and feature implementation list, that will only mean that maintenance or features will be done later/after Calibre maintenance.

As Sigil stands now, there will be NO maintenance or new features, except (maybe) if it breaks for some reason, on one of the operating systems.

I rather prefer a low(er) priority editor in development, than an unmaintained one; that's the primary reason why I'm advocating a re-implementation in Calibre.

[Hitch]

Originally Posted by Katsunami

Even if you prove to be correct, and a Calibre-hosted successor to Sigil IS on the bottom of the maintenance and feature implementation list, that will only mean that maintenance or features will be done later/after Calibre maintenance.

As Sigil stands now, there will be NO maintenance or new features, except (maybe) if it breaks for some reason, on one of the operating systems.

I rather prefer a low(er) priority editor in development, than an unmaintained one; that's the primary reason why I'm advocating a re-implementation in Calibre.

I understand your logic. As I said...when we get someone who steps up to handle the editor....

Hitch

[mrmikel]

I think calibre is more than I need and I seldom use its conversion functions. I also don't like it addition of extra and often incompressible css.

HOWEVER, we will sooner or later be up the proverbial creek without a Sigil.

However if your need is different from relatively HTML/CSS limited calibre user, I can see Hitch that is going to be a problem.

We might also have issues with an editor written in Python for speed, which again an issue for a production shop, rather than us plinkers, correcting error 4444 of 11111.

expletive deleted, expletive deleted, expletive deleted.

[Katsunami]

Originally Posted by mrmikel

I think calibre is more than I need and I seldom use its conversion functions. I also don't like it addition of extra and often incompressible css.

Calibre only changes the CSS on conversion.

However if your need is different from relatively HTML/CSS limited calibre user, I can see Hitch that is going to be a problem.

Why? The point of adding an editor to Calibre is exactly to make CSS-editing and such possible.

We might also have issues with an editor written in Python for speed

This is the only real disadvantage I can see. When opening EPUBs with lots of files, Sigil is already slow, but it seems to load everything into memory. Maybe it would be best to unzip the file to disk, and have the editor load one file at a time; comparable to what Tweak Book seems to do.

[Hitch]

Originally Posted by mrmikel

I think calibre is more than I need and I seldom use its conversion functions. I also don't like it addition of extra and often incompressible css.

HOWEVER, we will sooner or later be up the proverbial creek without a Sigil.

However if your need is different from relatively HTML/CSS limited calibre user, I can see Hitch that is going to be a problem.

Oh, I say, now....c'mon, I'm not going to "be a problem." I suspect I shan't get what I want in this particular environment. That doesn't make me a problem. I shall probably just be very, very cranky, and as I said sometime earlier, we may have to address our own internal solution. Can't say yet. Some White Knight or Lady may yet ride onto the scene.

We might also have issues with an editor written in Python for speed, which again an issue for a production shop, rather than us plinkers, correcting error 4444 of 11111.

expletive deleted, expletive deleted, expletive deleted.

mmmm....ditto, ditto, ditto.

In fairness, I certainly see Katsunami's point. I doubt he can really understand mine, which isn't that uncommon here (again: no disrespect to him or anyone else). A production environment is a very different scenario. {shrug}. The world turns, things change, and we must all adapt or perish. Thus 'tis ever so.

Hitch

[Katsunami]

Originally Posted by Hitch

In fairness, I certainly see Katsunami's point. I doubt he can really understand mine, which isn't that uncommon here (again: no disrespect to him or anyone else). A production environment is a very different scenario. {shrug}. The world turns, things change, and we must all adapt or perish. Thus 'tis ever so.

I try to see your point of view, but in my eyes, it seems to come down to this:

"If the EPUB editor is not a stand-alone program, then it can't do what I want."

Why is that? Why can a solution integrated into Calibre not do what you want?

I just don't understand.

Many parts of Calibre are seperate executables, such as "calibre-viewer.exe". After starting that, you can click "Open ebook", and you can open any book on your hard drive, without ever seeing Calibre itself.

In my view, the EPUB-editor could be called "calibre-editor.exe". You make a shortcut to doubleclick, and the editor pops up, with the option to open any EPUB, and having its own menu/buttons/interface, just like the viewer.

It will look and work like a stand-alone program, with functions comparable to Sigil as it is now (eventually), with the major difference that it has the entire Calibre infrastructure to support it in its functionality and future developent. Frankly, I think this advantage is so huge, that even if the editor would be a low priority part of Calibre, it would still be developed much faster than a seperate C++ Sigil version.

[Perkin]

Calibre is great at what it does and is useful for 'personal' ebup creation, it's just not as good as Sigil purely because of what it (calibre) actually does - and how it does it (to get from the html to epub).

@Katsunami, one small example to show some problems with having sigil in calibre.

We ave a nice well coded html with all it's resources (css/images/fonts)
(We're currently happy with formatting but later we're going to decide to change some)

Create two epubs - one in sigil one in calibre -->

Sigil ->
Import that html into Sigil add the fonts (as sigil doesn't include them on import),
add chapter splitmarks with a regex -> split on markers
run the toc-generator
add metadata
check validity
save epub.

calibre ->
add html file to book entry (calibre then rar's all the resources together)
convert to epub
(with the options of split at headers/ toc etc.)

Right, (for arguments sake) we'll assume that they are identical when displayed in e-reader

Now (some time later)...
We decide some of the formatting needs changing and several places throughout the book need a few of the paragraphs tweaked so they match some others.
Try editing the epub and see which you'd rather use to edit.

I think if sigil were added to calibre, a 'workaround' would need to be added (ONLY) for html imports, in which calibre did'nt run it's usual convert process, just did the split/toc/metadata stuff and left the html/css pretty much 'as is'.

[Jellby]

I've been following this discussion with interest. I haven't had anything interesting to say yet, though

But I now wonder: wouldn't it be better to continue this thread in the calibre forum?

[kovidgoyal]

Feel free to split off the last however many posts into a thread in the calibre development forum, I cant do it as I dont have moderation privileges for the Sigil forum.

[Jellby]

OK, I hope the splitting point makes sense...

Moderator Notice
Please, continue the discussion on calibre development in the new thread.

Other comments about Sigil and its future may be posted here

[user_none]

Originally Posted by varlog

Qt itself has a add-a-plugin ability - see "The Lower-Level API: Extending Qt Applications". I am sure the developer/s know it and have already considered it in the past and have perfect reasons for not implementing it. I suppose one of the reasons is amount of work involved. What I would like to know are the other reasons, if any, which are perhaps obvious when one knows insides of Qt and Sigil - but not to outsider like me.

@user_none: I would really really appreciate some response... please?

Yes Qt provides plugin support. Two issues using it.

The first and smaller issue is language support. You basically have a choice between C++ and QtScript. Which goes back to the whole people actually need to know C++...

The second and larger issue is there is more to plugin than loading them. That's what the system Qt provides does for you. It makes it easy to load plugins. A plugin can't do anything if there aren't hooks for it to tap into and actually do anything. That's the hard part that's going to take the most amount of effort.