Does Sigil need an epub e-reader component?

[eschwartz]

I'm not aware of any plans to modularize the codebase, but the biggest size cost is really the bundled python, Qt5, and ICU libraries. The whole "calibre" python module is 23 MB out of 170 MB. (The resources data is an additional 40MB, nearly half of which is just localization strings.)
The "ebooks" module containing format reading code is actually the largest code component!

(A couple observations on the connectedness of things: the ebook conversion pipeline is a dependency of the GUI library, because that's a central GUI component, it is a dependency of the viewer, because the viewer reads a ton of formats due to internally converting them all into calibre's common denominator OEB representation, and it is joined at the hip to the news collator because news recipes are just a specialized ebook format source. The server component is an alternative interface to the GUI, so both depend on the database management. The viewer and editor could theoretically be divorced from the library, but all three share a lot of common utility code anyway that isn't worth disentangling. There's very little savings to be had.)

So basically the main difference for users (at least on Linux distros with good packaging) when calibre 4.x comes around, will be that the download is "roughly the same size", but it will depend on qt5-webengine instead of qt5-webkit, and in practice sigil already depended on webengine but now webkit can be uninstalled.

I have actually pondered the thought of one day trying to split out the format code into a standalone module as it's the most obviously useful to other projects. But I'm rather busy at the moment. Someday...

...

BTW regarding python3, my secret was that I waited for someone else to ask, where "ask" involved submitting a giant Pull Request to make much of the python code syntax-compatible with python3 and get the C extensions to compile. I've then spent a ton of time building on that. So, much of the credit goes to @flaviut on Github... he took the first steps, I followed after and polished it up, taking advantage of the fact that I had a semi-viable codebase to actually try to run.

The moral of the story is more or less "in typical open source fashion, the best way to convince someone to change something is to write the code -- or at least a majority of it -- yourself". So I rarely if ever waste time asking Kovid to change how calibre is internally designed. Instead, I look at things which bother me, I ask "how can I fix this", and then I fix it and ask him if he agrees with my proposed solution. Kovid is a reasonable person and appreciates when people help make his job easier.

This is for example how I got calibre to build with system versions of mathjax, html2text, markdown, and feedparser, and how I got calibre ported *from* an internal fork of beautifulsoup3 to a system version of bog-standard bs4. (All these now use calibre's standard module freezing code instead of trying to merge bundled code into the source tree.) It's how I implemented a series of build system changes that mean I don't need to hack around DESTDIR installs (which every distro reinvents separately, usually incorrectly). It's also how I'm getting calibre slowly but surely ported to python3.

I will actually never understand why I am practically the only person who ever tried that, but it works. Instead, people try to "sway his opinion" by asking him to do a lot of work that doesn't help him, and, usually, by insulting him and (I'm mind boggled, but some people actually feel this way) telling him that the world is a worse place because calibre exists and prevents anyone else from being motivated to "do ebooks right".

[un_pogaz]

Originally Posted by eschwartz

Does Sigil need to develop its own competitive ereader as well?

Probably. I haven't found any really worthy leaders.

Originally Posted by eschwartz

Something to keep in mind is that calibre's ebook-viewer is in the middle of drastic changes.

Oh, crap. I look forward to seeing that.

But like KevinH, I hope it will be possible to install the ereader independently (or at least use it).
Personally, I am more in favour of creating several software that can be used independently, but that has a strong synergy between them, even if it means having to group them together in a single installer because they use a common code base (a software suite in short, like LibreOffice), rather than a big monster that makes all in one.
If Calibre points to this and separates each of its features, it will become even more perfect than it already has (but this is not the right forum for that )

BTW : The new feature of PageEdit is not especially intuitive to open in ereader mode and there is still a window/panels for the TOC missing, but navigation and reading is so much easier than in Sigil

[Springbok]

Looking at the current state of the PageEdit application and the fact that you guys already spent time and effort to migrate to new QtWebEngine platform making cross-platform epub reader would be in my opinion a natural thing to do.

Key feature here would be a reading progress sync feature across different platforms (Windows, OSx and Unix).

Under Windows there are not that many good epub reader programs. Calibre Viewer simply is not designed as a cross platform standalone application. I see it more like an extension to the Calibre Library Management function. Also Calibre viewer does not have sync function.

So, it does not look as your idea would a duplication effort.

[BetterRed]

Originally Posted by un_pogaz

If Calibre points to this and separates each of its features, it will become even more perfect than it already has (but this is not the right forum for that

FTR: some of calibre's major features are shipped as separate executables, e.g. the viewer, the ePub/AZW3 editor, and library server, and the library manager of course, see ==>> The Command Line Interface

And some calibre optional plugins can be used independently via the calibre-debug command.

Added: So, from a usage perspective it's not monolithic, even though its shipped as a single install.

BR

[eschwartz]

Originally Posted by BetterRed

FTR: some of calibre's major features are shipped as separate executables, e.g. the viewer, the ePub/AZW3 editor, and library server, and the library manager of course, see ==>> The Command Line Interface

It's nothing to do with the command-line interface, though...

Originally Posted by un_pogaz

But like KevinH, I hope it will be possible to install the ereader independently (or at least use it).
Personally, I am more in favour of creating several software that can be used independently, but that has a strong synergy between them, even if it means having to group them together in a single installer because they use a common code base (a software suite in short, like LibreOffice), rather than a big monster that makes all in one.
If Calibre points to this and separates each of its features, it will become even more perfect than it already has (but this is not the right forum for that )

Just like LibreOffice, calibre is a suite of software with several programs that share a common codebase, and thus synergy... what this means is that, like LibreOffice, the calibre installer will install several application launchers to the Start Menu (or desktop files on Linux).

If I remember correctly, Apple's technology for distributing applications on the macOS platform does not permit developers to provide multiple entry points for a single .dmg installer. Something about being "simple and easy to use". Therefore macOS is the odd operating system out when it comes to advertising that calibre has multiple GUI programs available. But even so, I think you should be able to start the E-Book Viewer or the Editor from within calibre, and then pin the icons to the dock.

Other alternatives would be to use a professional operating system meant for real users with real needs... oh sorry, did I say that out loud?
*ducks and runs*

[kovidgoyal]

The calibre e-book viewer is useable as a standalone program on all operating systems, including macOS (there is a separate ebook viewer bundle inside the main calibre bundle).

For instance, if you want to open a book using it from anther program you would do

open -a /Applications/calibre.app/Contents/ebook-viewer.app file.epub

Or if you dont want to use open

/Applications/calibre.app/Contents/ebook-viewer.app/Contents/MacOS/ebook-viewer file.epub

On other OSes, just do:

ebook-viewer file.epub

@Springbok: the calibre viewer most defintely syncs both reading position and bookmarks across operating systems. In fact, by default when reading epub files it stores this data inside the file, so to sync across OSes all you need to do is sync the EPUB file itself.

[kovidgoyal]

As for EPUB 3 features, I dont know what you have in mind, but calibre already supports all the actually useful ones, with the possible exception of page number maps and fixed layout books.

[Turtle91]

Hi Kovid - thanks for the clarification!

I know Calibre Reader has the ability to have custom CSS via the settings, but is there an option to use the publisher's included CSS?? If we are trying to use it for editing/design functions then using default CSS doesn't help.

[kovidgoyal]

The viewer always uses the CSS in the book. As with browsers, CSS cascade starts at the lowest level with the user agent styles, then the styles in the actual document, and finally any user specified styles.

[Turtle91]

Awesome! I guess I was confused (easily done) when I had the cover image lose its set ratio and fill the display screen using an SVG. Glad to see that it does indeed work!

[BetterRed]

Originally Posted by BetterRed

FTR: some of calibre's major features are shipped as separate executables, e.g. the viewer, the ePub/AZW3 editor, and library server, and the library manager of course, see ==>> The Command Line Interface

Originally Posted by eschwartz

It's nothing to do with the command-line interface, though...

Even calibre's GUI components have optional command line arguments - as documented in the The Command Line Interface section of the manual. If I want to start the library manager with no optional plugins I type calibre --ignore-plugins at the command line…

You know that, I know that, but we're probably not a representative sample of the One-Click generation

BR

[theducks]

Hey, we even read the Manual, checked the FAQ before calling on 'support'

[odamizu]

On macOS: Calibre > Show Package Contents > make alias of ebook-viewer or ebook-edit > drop alias in Applications folder (or wherever) and it functions as a standalone app, which can be kept in Dock, launched via Launchpad, or used to open ebooks using right-click, etc.

[democrite]

Perhaps no conclusion has been reached and the question remains opened. Some benefits: better performance due to using C++, some greater refinement such as native macOS scrolling that I'm unsure will make it into calibre someday, maybe a more native-looking app that Sigil itself might someday attempt, possible other features such as AppleScript that I'd guess might not never make it to calibre but since it seems one Sigil dev uses macOS, might be possible someday, and so forth.

[eschwartz]

"Sigil needs its own ebook editor because Calibre doesn't use C++" is not a convincing argument. And I haven't generally heard complaints about Calibre being too slow... many performance-critical parts are already implemented in Calibre as C/C++ extensions, anyway. The main slowdown in calibre's ebook-viewer is that for non-EPUB formats the viewer internally runs a format conversion first. And the latest version of Calibre will anyways fully cache the results of this conversion when opening in the viewer, so opening a book for the second time is almost instantaneous if it hasn't changed.

Native macOS scrolling... I don't know what this is, but have you tried asking Kovid to implement it? Native-looking apps sounds like something only macOS users would care about and something that would actively prevent me from using any new program developed by the Sigil developers (assuming it were inflicted on me with no option to disable it). AppleScript is another obvious macOS exclusive which I don't have any knowledge of, but again, why do you think it can or be implemented in Calibre? Can you explain what it would do and why one might wish to implement it?

Overall this seems to primarily be about some perception that Calibre is crippled on macOS due to lacking macOS specific features that macOS users care about. It seems like the easiest answer is to ask that they be implemented.

Not sure how this ties into "we need a fully independent from-scratch implementation of an ebook viewer written by the Sigil developers who we already trust.