Is anyone working on a Webkit2 port?



  • Cheers

    Long story short I have a couple of requirements that don't fit very well into QtWebEngine, - need fine grained control over network requests and portable code. I also have some old code using QtWebKit and I need to figure what to do going forward.

    By any chance is any one working on a WebKit2 Qt port using a recent version of Webkit? Or considering starting a new one? Even if it lacks some of the heavier (e.g. WebGL, Video) or more recent features.



  • Nobody replied after 4 months! I agree, QtWebEngine is nothing at all like QtWebkit? Very disappointing move.



  • I certainly have no trouble understanding why Qt moved to QtWebEngine, maintaining a WebKit cant be easy, specially the Multimedia/WebGL bits. I'm certainly not criticizing the decision.

    But I am kind of surprised that no one rebooted the WebKit Qt port by now (even if its not officially supported in Qt). The old QtWebKit module will be removed from Qt in the next release (5.6) right?

    There were several projects using QtWebKit that cannot get the same features out of QtWebEngine - browsers and setup-boxes (some commercial products) come to mind.

    BTW:



  • DISAPPOINTING indeed!!!
    If you ask me, it is the power of Google.

    The first thing that comes to mind is why Digia is not using WebKit2 instead of WebKit1 while they already have WebKit1 and WebKit2 ports for their products.

    This is what I know but correct me if I'm wrong (I might have missed some documents or announcements):

    • QtWebkit is WebkIt2 and is here for Qt5 but in conjunction with QML only.
    • QtWebKitWidgets/QWebView is WebKit1 (like it is right now in Qt4).
    • QtWebEngineWidgets is the current Chromium port.

    From a programmers point of view the QWebView (WebKit1) is superior compared to QWebEngineWidgets (Chromium) since QWebView has more classes/functions/methods that can be used. However, it is not that stable and it is 'outdated' for many complex (JAVA script based) websites (but for day to day use in less complex wesbsites it works great).

    If you do not use QML then you are forced to use QtWebKitWidgets (WebKit1) or the QtWebWengineWidgets. The QtWebKit (WebKit2) does not work outside QML.

    Now ....... I do believe that WebKit2 is a force that might be the pain in the ... for Google since QtWebEngineWidgets is not being ported to regular Android for mobile/tablet devices. Start wondering why......?

    QtWebKit (WebKit2) is however ported to Android and to iOS in the latest tech preview Digia made available this month (aug 2015).

    So.......
    Digia has a WebKit1 port
    Digia has a WebKit2 port
    Digia has a Chromium port

    but........

    • WebKit1 has by far the most classes/functions/methods a programmer can use but is 'outdated´ and not stable enough on complex JAVA script based websites. But is it fast and small, It is available on all platforms.

    • WebKit2 can only be used with QML (fast and small too, probably much more stable then WebKit1) and has much better support for complex JAVA script based websites.
      It is available on all platforms too.

    • Chromium is state of the art in supporting websites but is HUGE, slows down Qt apps and is NOT available on all platforms. Many Linux vendors do not even support QWebEngineWidgets due to too may dependencies and compiler issues. On top of that it has much less functionality in terms of exposed classes/functions and methods than WebKit1.

    Which leads me to believe that Google wants to be the sole ruler over webrowsers in Android devices and all other non-iOS devices (since that might be blocked by Apple).

    I would not be supprised if Google and Digia made a deal in which Google dictates Digia on what platforms the Qt port of Chromium should run (and it aint Android.....).


  • Moderators

    @theDAX said:

    This is what I know but correct me if I'm wrong (I might have missed some documents or announcements):

    • QtWebkit is WebkIt2 and is here for Qt5 but in conjunction with QML only.
    • QtWebKitWidgets/QWebView is WebKit1 (like it is right now in Qt4).

    Not quite. Both Qt WebKit and Qt WebKit Widgets use WebKit 2 (I know the documentation is misleading). However, Qt WebKit spawns multiple processes, while Qt WebKit Widgets spawns a single process.

    See the comments in https://codereview.qt-project.org/#/c/112356/1//ALL

    • QtWebEngineWidgets is the current Chromium port.

    Correct. There's also Qt WebEngine for QML.

    From a programmers point of view the QWebView (WebKit1) is superior compared to QWebEngineWidgets (Chromium) since QWebView has more classes/functions/methods that can be used. However, it is not that stable and it is 'outdated' for many complex (JAVA script based) websites (but for day to day use in less complex wesbsites it works great).

    Half-correct. Yes, the WebKit port is much more flexible than the Chromium port, and it works fine for simple web-based apps. However, it's less secure than Chromium -- security is important to programmers too.

    If you do not use QML then you are forced to use QtWebKitWidgets (WebKit1) or the QtWebWengineWidgets. The QtWebKit (WebKit2) does not work outside QML.

    Correct about QML.

    Now ....... I do believe that WebKit2 is a force that might be the pain in the ... for Google since QtWebEngineWidgets is not being ported to regular Android for mobile/tablet devices. Start wondering why......?
    QtWebKit (WebKit2) is however ported to Android and to iOS in the latest tech preview Digia made available this month (aug 2015).

    Wrong. Qt WebKit has not been ported to mobile/tablet platforms.

    iOS does not allow 3rd party web engines, so Qt WebKit and Qt WebEngine can never run on iOS (unless Apple changes its policies).

    So.......
    Digia has a WebKit1 port
    Digia has a WebKit2 port
    Digia has a Chromium port

    Correct (minus WebKit1) for desktop platforms.

    but........

    • WebKit1 has by far the most classes/functions/methods a programmer can use but is 'outdated´ and not stable enough on complex JAVA script based websites. But is it fast and small, It is available on all platforms.

    The first part is correct, but the second part is wrong: Both Qt WebKit and Qt WebEngine are unavailable on mobile platforms.

    How did you measure the performance difference between Chromium and WebKit?

    • WebKit2 can only be used with QML (fast and small too, probably much more stable then WebKit1) and has much better support for complex JAVA script based websites.
      It is available on all platforms too.

    See above.

    • Chromium is state of the art in supporting websites but is HUGE, slows down Qt apps and is NOT available on all platforms. Many Linux vendors do not even support QWebEngineWidgets due to too may dependencies and compiler issues. On top of that it has much less functionality in terms of exposed classes/functions and methods than WebKit1.

    Wrong.

    Linux distro maintainers don't have a problem with the number of dependencies; they didn't like Qt WebKitWidgets because it bundles an extra copy of all its dependencies. However, this is changing in Qt 5.6: http://comments.gmane.org/gmane.comp.lib.qt.devel/22913 (Lisandro is a maintainer for Ubuntu, and he's happy with the current direction)

    Again, you said that Chromium slows things down. How did you measure this?

    Which leads me to believe that Google wants to be the sole ruler over webrowsers in Android devices and all other non-iOS devices (since that might be blocked by Apple).

    I don't understand how you arrived at this conclusion, even if your earlier points were correct. Could you please explain?

    I would not be supprised if Google and Digia made a deal in which Google dictates Digia on what platforms the Qt port of Chromium should run (and it aint Android.....).

    A scandal like this would be very interesting... but reality is quite boring, sadly.



  • About QtWebkit (WebkKit2 according to me) and QtWebWidgets (WebKit1 according to me).

    Well what you say sounds interesting if they both are based on WebKit2 (and I realy do hope you're right so I can stick to WebKit2)

    BUT.......but .....this link shows me that it is in fact not:
    http://doc.qt.io/qt-5/qtwebkitexamples-index.html

    About the Linux maintainers and the availability of QtWebEngine
    See this link where the maintainers talk about compiling and packaging (it does'nt look good for QtWebEngine there). Note: I got it working but at a pretty labour intensive price.
    https://www.phoronix.com/scan.php?page=news_item&px=QtWebEngine-Mess-Debian
    and this one:
    http://kde-core-devel.kde.narkive.com/LJ3pjpxp/distros-and-qtwebengine

    About QtWebKit2 on Android and iOS
    You cant find it on the website of Qt but when I download the Qt online installer for Linux, I see in there the option to download the technology preview of QtWebKit for Android and iOS....... now how about that ;-)

    About performance
    That is my own observation using the examples. It is not that the WebEngine itself is slow..... it drags my userinterface to a crawl when I compare that to using webkit. This might because it is running in a VM with and without 3D accelerated...... but I do not have that issue with WebKit1...... but that has other issues though ;-)

    The force of Google
    There might be WebKit2 for Android and for iOS (without Google effort, see Technology preview)
    There is QtWebEngine (with Google effort) but NOT for Android...... why?

    Why, when Google itself has one for all Android versions...... Why is there not a Qt version of it for Android? That is what makes me believe that Google wants to control that part themself (and not by Qt developers or developers using Qt that can make an alternative version for Android).


  • Moderators

    @theDAX said:

    About QtWebkit (WebkKit2 according to me) and QtWebWidgets (WebKit1 according to me).

    Well what you say sounds interesting if they both are based on WebKit2 (and I realy do hope you're right so I can stick to WebKit2)

    BUT.......but .....this link shows me that it is in fact not:
    http://doc.qt.io/qt-5/qtwebkitexamples-index.html

    Sorry, you're right -- I misunderstood what Allan said.

    About the Linux maintainers and the availability of QtWebEngine
    See this link where the maintainers talk about compiling and packaging (it does'nt look good for QtWebEngine there). Note: I got it working but at a pretty labour intensive price.
    https://www.phoronix.com/scan.php?page=news_item&px=QtWebEngine-Mess-Debian
    and this one:
    http://kde-core-devel.kde.narkive.com/LJ3pjpxp/distros-and-qtwebengine

    Read my link above. It describes how Qt 5.6 will address these issues.

    About QtWebKit2 on Android and iOS
    You cant find it on the website of Qt but when I download the Qt online installer for Linux, I see in there the option to download the technology preview of QtWebKit for Android and iOS....... now how about that ;-)

    That sounds like a bug in the installer. (Did you try to run Qt WebKit on Android and iOS?)

    About performance
    That is my own observation using the examples. It is not that the WebEngine itself is slow..... it drags my userinterface to a crawl when I compare that to using webkit. This might because it is running in a VM with and without 3D accelerated...... but I do not have that issue with WebKit1...... but that has other issues though ;-)

    Yeah, I recommend doing benchmarks on physical machines, not virtual machines.

    The force of Google
    There might be WebKit2 for Android and for iOS (without Google effort, see Technology preview)
    There is QtWebEngine (with Google effort) but NOT for Android...... why?

    Why, when Google itself has one for all Android versions...... Why is there not a Qt version of it for Android? That is what makes me believe that Google wants to control that part themself (and not by Qt developers or developers using Qt that can make an alternative version for Android).

    There is no Qt WebKit for Android or iOS.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.