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