Qt 5.6 removing QtWebKit and Calibre's plans?

KevinH · 01-27-2016, 12:59 PM

Hi Kovid,

I recently found that Qt Webkit will be removed from Qt 5.6 (official Qt release builds will not include it but it will be there in source) and that according to Qt - no more releases of QtWebKit will be made and that all outstanding Qt webkit bugs will not be fixed.

So Sigil can either stick with Qt 5.4.2 or Qt 5.5.1 or convert over to QWebEngineView (which makes a few interface calls like page setting and javascript execution fully asynchronous, needing callbacks). That said, QtWebEngine official release builds do not support mp3 audio, mp4 video, due to licensing. So if we (Sigil) move to QtWebEngine we will have to build our own Qt for all 3 main platforms (Windows, Linux, and Mac OS X). Perhaps you already do your own Qt builds? The need to build Qt from source will definitely present a stumbling block to some users who build their own versions.

May I ask what your plans are regarding how Calibre plans to deal with the forced move from Qt WebKit to Qt QWebEngine? Do you plan to stick with Qt 5.4 (5.5.1) for some time yet or make the move to QWebEngine? And what your thoughts might be for what would be best.

Thank you.

KevinH

kovidgoyal · 01-27-2016, 10:38 PM

Qt is going to keep WebKit around for the lifetime of Qt 5.x. They may or may not stop releasing it in 5.6 (I have seen conflicting info on that on the Qt and KDE mailing lists). But they will make a source code release of it available.

Qt (and indeed all calibre dependencies) is built from source in calibre in any case, so I plan to keep using it for the lifetime of Qt 5. Once Qt 6 arrives, I will takeover maintenance of Qt WebKit myself (just as I already maintain a fork of python 2.7 that builds with Visual Studio 2015).

In the long term I will of course gradually phase out Qt WebKit from calibre in favor of a mix of QWebEngine and the Chromium Embedded Framework. The problem is that in calibre Qt WebKit is used in far more sophisticated ways that WebEngine cannot replace. For example, as an automated headless browser and to render HTML to PDF.

I have a good deal of experience with QWebEngine (having written my own browser using it https://github.com/kovidgoyal/vise) and once a few outstanding bugs are fixed, it should be fairly easy to port the preview panel and viewer in calibre to web engine. I imagine the same is true for Sigil's preview panel (although I am not sure about your Book View mode, since I dont know the details of how it operates).

I suggest you continue using WebKit in the short to medium term and start thinking about porting Sigil to WebEngine after a few more releases in the Qt 5.x line (I'd say Qt 5.7), when WebEngine is more mature -- note that currently Qt has not even ported their own Qt Assistant application to WebEngine. I have to say I have been less than impressed with Qt's project management.

KevinH · 01-28-2016, 07:34 AM

Yes, Bookview uses the QWebElement API which has no equivalent in QWebEngine and Preview includes a QWebInspector which doesn't seem to exist either. So we will stick with Qt 5.5.1 and start building our own after that.
Thanks for the advice.
KevinH

DiapDealer · 01-28-2016, 09:18 AM

Quote:

Originally Posted by kovidgoyal

I will takeover maintenance of Qt WebKit myself (just as I already maintain a fork of python 2.7 that builds with Visual Studio 2015).

Oh my. I almost had Python3.4 building well with VS2013 (to have a uniform Windows Sigil/Python/Qt runtime), but ran into a few snags. I may have to peruse your fork for inspiration!

I admit I'm not really looking forward to a "VS2105 For Everything" dev-environment overhaul.

kovidgoyal · 01-28-2016, 10:11 AM

@DiapDealer Python 3.5 is built with VS 2015, so if you are willing to switch to that, you dont need to do any work. In any case, if you wish to peruse my fork, feel free -- it can be found in my github profile.

@KevinH: Most QWebElement usages can be replaced (with a bit of work) by pure javascript. As for web inspector, that exists in QWebEngine, although in an insecure form. See https://bugreports.qt.io/browse/QTBUG-50725

KevinH · 01-28-2016, 10:22 AM

As far as I can tell, our usage of QWebElement in BookView is to retrieve layout geometry information from the currently selected position being editing inside BV so that positional scrolling can be controlled independent of the user needing to move the scroll bars. I will have to look into how to use javascript to get geometry information from the layout engine. I did not know that was doable.

Thanks,

KevinH

Quote:

Originally Posted by kovidgoyal

@DiapDealer Python 3.5 is built with VS 2015, so if you are willing to switch to that, you dont need to do any work. In any case, if you wish to peruse my fork, feel free -- it can be found in my github profile.

@KevinH: Most QWebElement usages can be replaced (with a bit of work) by pure javascript. As for web inspector, that exists in QWebEngine, although in an insecure form. See https://bugreports.qt.io/browse/QTBUG-50725

kovidgoyal · 01-28-2016, 10:24 AM

Use getBoundingClientRect()

DiapDealer · 01-28-2016, 10:44 AM

Quote:

Originally Posted by kovidgoyal

@DiapDealer Python 3.5 is built with VS 2015, so if you are willing to switch to that, you dont need to do any work. In any case, if you wish to peruse my fork, feel free -- it can be found in my github profile.

Yes.I was actually looking forward to being able to use precompiled Qt and precompiled Python under one uniform VS2015 runtime with Sigil, but the removal of WebKit from the precompiled Qt5.6 may put a damper on that.

Building Qt itself isn't the main hurdle for me right now (Windows or Linux). It's the fact that a custom Qt requirement on Linux means that I need a stand-alone Linux installer for Sigil waiting in the wings once the various distro-provided Qt5s are rendered insufficient for the job. I'm not opposed to a binary Linux Sigil intaller (a la calibre), but let's just say I haven't been quite up to the task of producing a robust one so far.

kovidgoyal · 01-28-2016, 10:46 AM

As far as I know, most distros are going to keep on producing Qt WebKit packages for the lifetime of Qt 5.x -- there are way too many applications that depend on it for them not to do so, and I have seen positive statements to that effect from the maintainers of a couple of distros.

EDIT: And yeah, producing robust cross distro binaries on linux is a major PITA -- the linux distro situation in general is a major PITA.

01-27-2016, 12:59 PM	#1
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Qt 5.6 removing QtWebKit and Calibre's plans? Hi Kovid, I recently found that Qt Webkit will be removed from Qt 5.6 (official Qt release builds will not include it but it will be there in source) and that according to Qt - no more releases of QtWebKit will be made and that all outstanding Qt webkit bugs will not be fixed. So Sigil can either stick with Qt 5.4.2 or Qt 5.5.1 or convert over to QWebEngineView (which makes a few interface calls like page setting and javascript execution fully asynchronous, needing callbacks). That said, QtWebEngine official release builds do not support mp3 audio, mp4 video, due to licensing. So if we (Sigil) move to QtWebEngine we will have to build our own Qt for all 3 main platforms (Windows, Linux, and Mac OS X). Perhaps you already do your own Qt builds? The need to build Qt from source will definitely present a stumbling block to some users who build their own versions. May I ask what your plans are regarding how Calibre plans to deal with the forced move from Qt WebKit to Qt QWebEngine? Do you plan to stick with Qt 5.4 (5.5.1) for some time yet or make the move to QWebEngine? And what your thoughts might be for what would be best. Thank you. KevinH

01-27-2016, 10:38 PM	#2
kovidgoyal creator of calibre Posts: 43,858 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Qt is going to keep WebKit around for the lifetime of Qt 5.x. They may or may not stop releasing it in 5.6 (I have seen conflicting info on that on the Qt and KDE mailing lists). But they will make a source code release of it available. Qt (and indeed all calibre dependencies) is built from source in calibre in any case, so I plan to keep using it for the lifetime of Qt 5. Once Qt 6 arrives, I will takeover maintenance of Qt WebKit myself (just as I already maintain a fork of python 2.7 that builds with Visual Studio 2015). In the long term I will of course gradually phase out Qt WebKit from calibre in favor of a mix of QWebEngine and the Chromium Embedded Framework. The problem is that in calibre Qt WebKit is used in far more sophisticated ways that WebEngine cannot replace. For example, as an automated headless browser and to render HTML to PDF. I have a good deal of experience with QWebEngine (having written my own browser using it https://github.com/kovidgoyal/vise) and once a few outstanding bugs are fixed, it should be fairly easy to port the preview panel and viewer in calibre to web engine. I imagine the same is true for Sigil's preview panel (although I am not sure about your Book View mode, since I dont know the details of how it operates). I suggest you continue using WebKit in the short to medium term and start thinking about porting Sigil to WebEngine after a few more releases in the Qt 5.x line (I'd say Qt 5.7), when WebEngine is more mature -- note that currently Qt has not even ported their own Qt Assistant application to WebEngine. I have to say I have been less than impressed with Qt's project management. Last edited by kovidgoyal; 01-27-2016 at 10:46 PM.

01-28-2016, 07:34 AM	#3
KevinH Sigil Developer Posts: 7,644 Karma: 5433388 Join Date: Nov 2009 Device: many	Yes, Bookview uses the QWebElement API which has no equivalent in QWebEngine and Preview includes a QWebInspector which doesn't seem to exist either. So we will stick with Qt 5.5.1 and start building our own after that. Thanks for the advice. KevinH Last edited by KevinH; 01-28-2016 at 09:40 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
calibre future plans?	alexxx	Calibre	1	11-26-2014 08:29 AM
PRS-T1 [Solved] Reader for MAc missing QtWebKit	pholy	Sony Reader	3	05-27-2012 01:23 PM
Removing Calibre from Linux	Logseman	Calibre	2	08-23-2010 12:54 PM
removing books from calibre	artemisblossom	Calibre	2	08-02-2010 11:19 AM
Any plans to add MTP to calibre?	=X=	Calibre	3	09-30-2009 11:46 PM

01-28-2016, 10:11 AM	#5
kovidgoyal creator of calibre Posts: 43,858 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	@DiapDealer Python 3.5 is built with VS 2015, so if you are willing to switch to that, you dont need to do any work. In any case, if you wish to peruse my fork, feel free -- it can be found in my github profile. @KevinH: Most QWebElement usages can be replaced (with a bit of work) by pure javascript. As for web inspector, that exists in QWebEngine, although in an insecure form. See https://bugreports.qt.io/browse/QTBUG-50725

01-28-2016, 10:24 AM	#7
kovidgoyal creator of calibre Posts: 43,858 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Use getBoundingClientRect()

01-28-2016, 10:46 AM	#9
kovidgoyal creator of calibre Posts: 43,858 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	As far as I know, most distros are going to keep on producing Qt WebKit packages for the lifetime of Qt 5.x -- there are way too many applications that depend on it for them not to do so, and I have seen positive statements to that effect from the maintainers of a couple of distros. EDIT: And yeah, producing robust cross distro binaries on linux is a major PITA -- the linux distro situation in general is a major PITA.

Advert

Advert