How to make Sigil live

[Katsunami]

Originally Posted by jbacelar

Ah Kovid! you are great.

Indeed.

Who needs a WYSIWYG editor?
With the code editor and the preview window, I think that's enough.

Agreed. An updating preview is enough. Edit, save, update preview. I often use LilyPond (a sheet music language, a bit like TeX), and one of its main editors, Frescobaldi, works like this. It's enough.

Originally Posted by kovidgoyal

So to move this conversation along, here's a concrete offer. I offer to implement the *rest* part of it -- list of files, edit metadata, edit tocs, renaming/moving files, editing the spine, various automated actions from the Polish Books component -- if someone will volunteer to tackle the editor component.

I can set up a basic GUI shell that does most of that in a few weeks, and then let whoever volunteers work on the editor component. But, I will only spend the time to do that if I get a firm commitment from someone to handle the editor part. That committment will need to include ongoing support for fixing bugs in the editor component.

Thanks for this offer. If I had known anything about Python, and known more about GUI programming with QT (I'm normally one of the guys that does the stuff you never see, and what I did with GUI's was in C# and previously Delphi), I would have committed to this. As it stands now, I do not know if I have the skills (yet).

I need/want an option to edit EPUB. As I don't yet know if I can help to program it, however much I'd want to, I can at least offer to use it from the start (with Sigil as a backup), and test all the new functions.

[mrmikel]

I think if it is a matter of having Sigil continue to develop, WYSIWYG is a small price to pay. Sigil's audience can work in the code window anyway.

Those who find Sigil hard should probably be in AWP which IS a word processor or other similar program.

[Katsunami]

Originally Posted by mrmikel

I think if it is a matter of having Sigil continue to develop, WYSIWYG is a small price to pay. Sigil's audience can work in the code window anyway.

I hate WYSIWYG. It *ALWAYS* goes wrong at some point.

@Kovid
@user_none

Are the parts to edit an EPUB going to be seperate parts? I mean, are we going to have:

- Calibre itself for metadata
- TOC editor
- Explode/Tweak book
- An internal editor
- Every function as a plugin, with a button on the toolbar (lots of buttons)
- ... anything else needed ....

Or would it be better to fold all of that into a single "Tweak Book" window/editor that combines all editing functions in the same way Sigil does? (Apart from the Metadata of course).

[kovidgoyal]

The way I see it working is that tweak books will get replaced by a dedicated GUI, with the various functions like edit toc, polish books etc. available as wizards from within that GUI. The GUI will have an editor component to directly edit the html/css and wizards for re-odering/manipulating the spine, adding/deleting/renaming files and so on.

The various wizards will be based on the (already modular) components in calibre.

The actual editor component design is not something I have thought much about. Personally, I just use vim to edit epub or azw3 component files, so I dont have a good idea of what is needed.

[mrmikel]

One of the big features of Sigil is packaging the book together: getting the file listing and references handled automatically and getting it zipped back together correctly. You just insert an image into the html and Sigil handles the references in content file.

One thing that would be great if someone could do it is to make it possible to save ourselves from a bad replace all. Now the only salvation is a previously saved copy.

To the extent it can be modularized it would facilitate handling epub3 vs epub2. Now Sigil merely tolerates epub3 (which is fine with me since I have an older reader anyway.)

[Katsunami]

Originally Posted by kovidgoyal

The way I see it working is that tweak books will get replaced by a dedicated GUI, with the various functions like edit toc, polish books etc. available as wizards from within that GUI. The GUI will have an editor component to directly edit the html/css and wizards for re-odering/manipulating the spine, adding/deleting/renaming files and so on.

The various wizards will be based on the (already modular) components in calibre.

I see it like that as well; replace Tweak Books with a dedicated EPUB editor/GUI combining all the features. Great

The actual editor component design is not something I have thought much about. Personally, I just use vim to edit epub or azw3 component files, so I dont have a good idea of what is needed.

The things I personally use most from Sigil:

- Add or delete TOC entries and Indent/Unindent TOC entries
- Rename all files to something like "Lastname_ISBN_1" (2, 3, 4, and so on)
- Clips
- Metadata Editor (Even though it seems to destroy Calibre's <dc:date>: If I use the metadata editor, I *must* put in the publication date, or it will be gone if I re-import the book into Calibre.)

But most of all, I rely on Sigil to keep things like the TOC/NCX/OPF file correct; sometimes though, I change the "guide" part in the OPF, if it makes the book behave weirdly. The Kindle seems to be particular about that, somehow.

For my part, there does not need to be a WYSIWYG-editor. If the editor switches between code editing and preview in a browser component by clicking on the tab or on a button, then it's enough for me; I think it's enough for anyone regularly using Sigil. I doubt that there are Sigil users who fully and only rely on the WYSIWYG-editor.

By the way: which bindings does Calibre use to call QT? PySide or PyQT, or even something else?

Originally Posted by mrmikel

One of the big features of Sigil is packaging the book together: getting the file listing and references handled automatically and getting it zipped back together correctly. You just insert an image into the html and Sigil handles the references in content file.

Yes, this. It's the most important part of the program, IMHO.

[DiapDealer]

By the way: which bindings does Sigil use to call QT? PySide or PyQT, or even something else?

If you mean calibre ... it uses PyQt. Sigil just calls Qt directly.

[Katsunami]

Originally Posted by DiapDealer

If you mean calibre ... it uses PyQt. Sigil just calls Qt directly.

Yes, I meant Calibre. Thanks. I've edited that.

[jbacelar]

Do not forget: Splitting and Merging, Find & Replace (regex), Saved searches for Find & Replace, Links and IDs, Indexes, Spellcheck, Reports ....

[Katsunami]

Originally Posted by jbacelar

Do not forget: Splitting and Merging, Find & Replace (regex), Saved searches for Find & Replace, Links and IDs, Indexes, Spellcheck, Reports ....

Splitting and Merging can be important for someone who is creating an ebook, but (IMHO) not so much to someone who is fixing it. If one must do a split or merge, it can be done manually, if nothing else. Not that this function can't be built in at some point of course.

Find/Replace obviously is important. Stupid that I forgat that. An editor without F/R is not very useful

[jbacelar]

A epub can be done manually in full with a normal editor (Vim, Notepad etc). Ask Jellby.
But I think that if someone wants to do a Sigil without these important features, it is best to save that job, because Sigil's users ... We have Sigil!

[Hitch]

Originally Posted by Katsunami

Splitting and Merging can be important for someone who is creating an ebook, but (IMHO) not so much to someone who is fixing it. If one must do a split or merge, it can be done manually, if nothing else. Not that this function can't be built in at some point of course.

Find/Replace obviously is important. Stupid that I forgat that. An editor without F/R is not very useful

Splitting & Merging is important for some of us.

I think that there's clearly a world of difference between fixers of ePUBs and makers of ePUBs, when I read this thread.

Hitch

[Katsunami]

Originally Posted by Hitch

Splitting & Merging is important for some of us.

I think that there's clearly a world of difference between fixers of ePUBs and makers of ePUBs, when I read this thread.

There is.

I make epubs from scratch very seldom, but I fix about everything I buy in some way or another. Splitting and merging is not very important when fixing stuff, but it is when creating books from scratch.

Now... Do we want Sigil's replacement to be a full fledged creation tool from the start, or do we start out by making it a "Tweak Book" on steroids, and then extending it from there, until it finally overtakes Sigil?

I think the second option would yield an already usable feature in Calibre faster.

[theducks]

Lots of Steroids

[Perkin]

When fixing editing epubs, one of the most often uses of Sigil for me (apart from quick spelling mistake edits) is having the handy ability to split and merge, keeping track and updating all the file/link references without Sigil would be a nightmare.

When building my own epubs (personal use), I have the html source file and any images/css/fonts
Once I import a html file, and the resources linked in it, I usually run the 'Split at markers', then 'Generate ToC', Check the metadata, fix semantics, check the validity, then save the epub. Job done (usually).

If you do the same import in calibre, a lot of styling etc is flattened and you end up with loads of 'calibre###' styles - not as nice as the given style names if you then need to edit the epub at any point.

So even if in future Sigil is embedded in calibre I'd still want the existing Sigil (or it's abilities) so any simple html-epub conversions don't get calibre'd.