[user_none]

Originally Posted by Katsunami

I see. It seems Scintilla is omnipresent. I have been unable to find another text editor component that even comes close to Scintilla's features. What component does Sigil use; or did you write it yourself?

Scintilla is indeed widely used. That doesn't make it any easier to work with. It just means there isn't much else out there for reusbable editing widgets. Most such components are project specific.

The one Sigil uses is a subclass of QPlainTextEdit with a lot of functionality added. Look qt QtCreator. It uses the same technique for their editor. There really isn't any reason it can't be as powerful as Scintilla. It just isn't there yet.

Originally Posted by Katsunami

Is this something that is not possible, because the editor itself has to "know" EPUB?

The editor itself doesn't have to know about it but Sigil was never designed to be used as library. It does not have an API to broker editing operations. A lot of the operations rely on the GUI components. Some of the information about the EPUB is stored in GUI widgets and pulled out of it when needed. It's not all in one nice and easy to access place that can be decoupled from the GUI.

Originally Posted by Katsunami

Why would you recommend against this approach?

The approach is fine. I'm saying I wouldn't recommend trying. You'd be better off starting over and looking at how Sigil deals with certain cases then coding that then trying to turn Sigil into a library.

Originally Posted by Katsunami

No, what I meant was to write a text editor based on a well-known text editing component, but with the addition of being able to open and save EPUB files. Then, Sigil's features could be implemented one by one.

All of the editors I mentioned can open and save epubs. They lack the advanced editing components such as a metadata editor but the basics and the starting point you've mentioned they already do.

I just feel that the focus should be on differentiating a rewrite from other editors. Focus on what those editors that can open and save epubs don't offer. If your goal is create an editor that can't do with Sigil already does and what other editors already do then worry at that time start thinking about how to add the epub features you're taking the wrong approach.

Originally Posted by Katsunami

If it would be possible to put Sigil's EPUB capability into a library (so, to open an EPUB, hand out an object with everything in it, and also save an EPUB if the library receives such an object back again), then it may be possible to fork an existing editor that already has a plugin structure, tack the EPUB library beneath it (coupled to its Open and Save functions), and then write the other needed parts as plugins.

If it were easy to make Sigil into a library then this approach would work. But as I said Sigil was never designed to be library and you can't decouple most operations from the GUI.

Originally Posted by Katsunami

I know. Where did you acquire the knowledge to program this? "Just read the EPUB spec" wouldn't cut it, I think. Of course I can implement specifications, but I have never done anything as large as EPUB from scratch and on my own.

Honestly, reading the spec. It's all there. That said reading the spec doesn't mean you need to read all of it. Read about how an epub is structured. Implement opening. Look at the parts that deal with content but only html. Implement it. Read the part about images. Implement. Repeat.

Once you have an over view of the format focus on the parts you actually need to care about when you need to worry about them. This does mean you'll end up having to recode when you read something later on that you didn't account for but you'll save in the long run by not spending time designing around features you'll never implement.

Sigil doesn't touch and completely ignores parts of the epub spec. Other than a basic over view of those parts I don't know implementation details.

Finally, understanding the epub format has a lot to do with calibre. I've implemented conversion for a number formats. Calibre's conversion pipe line is in -> OEB (basically the guts of an epub) -> out. That has helped a lot.

Originally Posted by Katsunami

Agreed. C++, and certainly C on their own are just languages, with relatively small libraries. To do anything meaningful without spending 50 years to do it requires extra libraries. Learning a new language is not the problem nowadays. That's a work a few days at most, and some experimenting. It's all the gazillion libraries and their workings.

This is one of the advantages of languages like Python. They come with a standard library. Typically if the standard library supports something that's what you learn and use. There is little need to have to choose between multiple libraries that do the same thing.

The Python community even takes this even further. XML libraries like lxml actually use the same API as the XML API that comes with Python. So transitioning between the two is pretty much seamless.

Originally Posted by Katsunami

How much work would you think it to be, if Calibre was extended with an EPUB/AZW3 file explorer and a code editor, based on some already existing component?

Shouldn't be long. Calibre's book object will have a list of files. Show the list. When an item is selected load it into an editor. When the editor loses focus replace the file's contents with the data from the editor.

As for the editor you'll need a good editor. I was looking at this and it would work with minimal tweaking. It uses the subclassed QPlainTextEdit concept I spoke about.

Look at this, this, and this blog post I wrote for examples of extending and working with QPlainTextEdit. These concepts are the basis of what Sigil, QtCreator and Spyderlib do to provide their editors.

Hooking in the regex stuff would be the hardest part but python has very strong regex (search and replace) support. You'd essentially get the data from the editor, run the search, get the offsets and highlight that area of the editor.