How to make Sigil live

[st_albert]

Originally Posted by theducks

The typical 'Creator' as seen here at MR appears to not want to get down and dirty with the code.

I was thinking just the reverse. I thought of myself as a "creator" in the sense that I am making previously non-existing epubs out of, say, word processor files. But on further reflection, I think you have the right of it. I don't in fact use sigil to produce the "proto epub." I use other tools for that, such as writer2xhtml, or InDesign export. Then I use sigil to "fix" them. So I really am a "fixer" after all.

Albert

[Hitch]

Originally Posted by mrmikel

Hitch could you list your must haves and serious wants so that if someone is interested in this they have some idea of the important tasks? As you said, creators have a different set of needs than fixers. I expect there are more fixer users, and many hobbyists. But you depend on it for a living which in my book moves you to the head of line.

mrmikel:

You are very considerate. Yes, I shall. Would it be alright if I didn't do this until Monday? I've just dropped in for a moment; I'm actually taking the first two days off in a row I've had in 5 years (actually 3--yesterday, also, but it was errands-I've-put-off-for-months day), and I'd love it if I could not think about the business until Monday. If it's needed before that, I'll jump in, TYSM.

Hitch

[mrmikel]

Since the white knight on his/her steed hasn't showed up yet, it seems it can await your convenience.

May you enjoy no thoughts of ebooks for an entire two days!

I am not so fortunate as I am reading a posted work of mine and discovering an error or two...eating one's own dog food is not always a treat.

Mike

[kacir]

Originally Posted by Katsunami

Can I have a second instance of Calibre (copy the folder?) so I can write code for that, without crashing my normal install?

You got answer from Kovid about setting an environment variable.
I personally would consider a virtual machine

[varlog]

This is an unexpected and very nice development - I mean potentially including of Sigil functionality in Calibre. It belongs of course to category "let's do something else".
Speaking for myself only: I like Sigil as it is now, a standalone dedicated program with a nice standard (or as good as) user interface - so I'll bore () a little bit longer.
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.

[DrChiper]

Originally Posted by varlog

I like Sigil as it is now, a standalone dedicated program with a nice standard (or as good as) user interface - so I'll bore () a little bit longer.

I also suggest to leave the new sigil (Sigil+ ?) as a standalone program and refrain from overload calibre with features. Making calibre Sigil+ aware for seamless cooperation is paramount though.

Just my 2cts.

[mrmikel]

I am willing to take what I can get and what is on offer, as I understand it, is to use the existing calibre infrastructure to support Sigil functions, not to support a separate program. That is, IF someone will create and support the text editing portion. No one yet has volunteered to do this.

I can understand why Kovid does not want to increase his support responsibilities by creating an entirely separate program with its own set of issues and dependencies.

[DrChiper]

What I meant to say (but obviously did not ) is that the Sigil+ (when it IS realized within calibre) should have its own appearance (separate window if you like) with dedicated GUI (similar to current Sigil) the way it is done for the ebook-viewer (or lrfviewer).

[Katsunami]

Originally Posted by DrChiper

What I meant to say (but obviously did not ) is that the Sigil+ (when it IS realized within calibre) should have its own appearance (separate window if you like) with dedicated GUI (similar to current Sigil) the way it is done for the ebook-viewer (or lrfviewer).

As I understood from earlier posts, the editor component, TOC editor, and all other parts needed to navigate within the book will be combined within one window. It would seem be the most logical; it's not very logical to recreate Sigil's functionality and then splatter them all around calibre, each with their own plugin button.

With regard to writing the editor component: I'm looking into this and experimenting somewhat with Python and QT. At this point I do not yet feel confident enough to say "I will write and support this editor component", as I don't have 8 hours a day to learn this stuff as I would on a regular job

[EowynCarter]

Originally Posted by DrChiper

I also suggest to leave the new sigil (Sigil+ ?) as a standalone program and refrain from overload calibre with features. Making calibre Sigil+ aware for seamless cooperation is paramount though.

Just my 2cts.

Ditto !

[mrmikel]

Originally Posted by Katsunami

At this point I do not yet feel confident enough to say "I will write and support this editor component", as I don't have 8 hours a day to learn this stuff as I would on a regular job

That is the crux of the issue for user none. He does have full time job writing payment system software, and Sigil got to be just too much. It appears he was willing to do people a favor, but not give up everything else in his life in the bargain.

I think the key is for our "white knight" to find some software already out there that will handle 70% of the job, so it isn't necessary to re-invent everything in the editor. It would only be necessary to trim and tuck here and there on the editor and add particular epub features and necessities.

If something like that can be found, it would reduce development and support time. It is the follow up and support that is the crux of the issue. For editing epub2, we can live with existing Sigil. As little as some of us like it, epub3 will be a larger and larger issue as time goes by and this version ought to handle epub3 and epub2 both without requiring a total rewrite.

[Katsunami]

Originally Posted by mrmikel

That is the crux of the issue for user none. He does have full time job writing payment system software, and Sigil got to be just too much. It appears he was willing to do people a favor, but not give up everything else in his life in the bargain.

Yes. I write software for a living as well, but not in Python, and not using GUI frameworks. Last time I created a GUI was in Visual Studio (drag and drop), that called the business logic in a DLL. It was a simple GUI as well; just a menu, some windows, and a button here and there.

Completely studying up on QT, EPUB, and all libraries Sigil is currently using to take over the program from user_none is too much work for me. I'm not willing to spend that effort.

I think the key is for our "white knight" to find some software already out there that will handle 70% of the job, so it isn't necessary to re-invent everything in the editor. It would only be necessary to trim and tuck here and there on the editor and add particular epub features and necessities.

Inheriting from QT's text editor component (user_none says it's QPlainTextEdit) already gets the basic editor in place, and "just" needs extension, which can be done in Python rather than in C++.

Also, Calibre already supports a lot of stuff, such as exploding and packing EPUBs (Tweak Book), embedding metatada (Calibre itself), TOC Editor (recently added), so all of that does not have to be re-written anymore.

I may not be a white knight yet, but I may become a grey one, exactly because of this.

If something like that can be found, it would reduce development and support time. It is the follow up and support that is the crux of the issue. For editing epub2, we can live with existing Sigil. As little as some of us like it, epub3 will be a larger and larger issue as time goes by and this version ought to handle epub3 and epub2 both without requiring a total rewrite.

Building a Sigil-like editor into Calibre at this time is one of the best things one could do, because if/when Calibre gets to support EPUB3 as input/output, it (almost) automatically supports it in this new editor. The functionality to explode and pack EPUB3 files in Calibre can be re-used for the editor, and the editor itself only needs to be extended, not rewritten.

Calibre will be transformed to some sort of "Adobe Lightroom of e-books". If you don't know Lightroom: it does with RAW image files what Calibre does with e-books, but it also contains facilities for editing these RAW image files. (And then, export them to JPG or other formats.)

The only downside is that people who *only* need an editor, also get an entire library manager with it, or people who want a library manager get an editor too. Same with Lightroom; there are people that use only the editor part, by temporarily importing RAWs into Lightroom, and removing them after they're done, but there are also people that use Lightroom as a library, and edit the RAWs in a different editor because they like that editor better.

I don't see this as a problem, if the editor part of Calibre is contained within its own form. Calibre already contains stuff I don't use (the Content Server for example), but it's not in the way, so I'm not bothered by it being there.

[theducks]

Originally Posted by DrChiper

I also suggest to leave the new sigil (Sigil+ ?) as a standalone program and refrain from overload calibre with features. Making calibre Sigil+ aware for seamless cooperation is paramount though.

Just my 2cts.

I am with you.
I am tired of making a bloated 'Swiss Army Knife' out of everything.

Make a program (Sigil already is. Flightcrew isn't.) that can launch from a CLI and possibly supply a 'return status' code and call it Done.

The USER picks their choice of tools.

The users guide could give examples of linked programs (or how to link from X)

[Hitch]

Originally Posted by mrmikel

That is the crux of the issue for user none. He does have full time job writing payment system software, and Sigil got to be just too much. It appears he was willing to do people a favor, but not give up everything else in his life in the bargain.

I think the key is for our "white knight" to find some software already out there that will handle 70% of the job, so it isn't necessary to re-invent everything in the editor. It would only be necessary to trim and tuck here and there on the editor and add particular epub features and necessities.

If something like that can be found, it would reduce development and support time. It is the follow up and support that is the crux of the issue. For editing epub2, we can live with existing Sigil. As little as some of us like it, epub3 will be a larger and larger issue as time goes by and this version ought to handle epub3 and epub2 both without requiring a total rewrite.

Hmmm. I think if something out there already did "70% of what's needed," this conversation would be over.

Myself, I'm not really in favor of blending Sigil into Calibre. Yes, I know that many of you use Calibre to convert PD books, etc., but we don't. I use Calibre as a cataloging tool. We don't use it to make books. I'm feeling rather apprehensive about the entire approach. I feel as though what is happening, as I look at this thread, is that Sigil's functions will be subsumed into Calibre, and the power and strength of Sigil will, by necessity, end up being directed at Calibre's user-base, which has extremely little in common with "my" user base, or the folks that use Sigil to make ePUBs from scratch (from already-cleaned HTML, or what-have-you).

This is not to discount or denigrate or in any way appear ungrateful to Kovid; his offer is extremely generous. But his user base and ours are not the same. Calibre attracts users like the people here--find PD book, run it through Calibre to get a base, then clean it up; or buy a book, hate the coding, run it through Calibre to get a base, then clean it up--or it attracts people that I see often, who don't want to know from HTML, so they take a PDF and run it through Calibre to get an ePUB or MOBI (or whatever).

I just can't see that Sigil's primary functions, as an ePUB editor, will end up being supported very heavily by the mainstay of the Calibre users, which means that Kovid's attentions, and that of the people who donate their time or money there, won't be on that. I mean, we're all sitting here right now waiting for someone to say, "Oh, I'll write the editor," and this is a forum full of Sigil-ites.

Just my observation, at this point in the discussion. (I don't code in C++, or in Python, for that matter, just so that's clear, or I'd donate my own time.)

Hitch

[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.

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.

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.

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.