12 ms·

Introducing the Qt WebEngine

106 points by ddb 13y ago

nicholassmith 13y ago
This is really interesting, because whilst Qt Webkit was a fantastic effort it had some quirks. Last project I was working on used Qt Webkit to provide a basic browser, so there was lots of fun with flash player integration, Javascript going awry and so on, if they're relying on Chromium to act as the core it should remove a lot of those headaches for developers and allow them to build on top of it much easier. Definitely a big change, quite exciting though.
- jdboyd 13y ago
  Since Chromium doesn't support flash (that is one of the closed source bits added to Chrome), I suspect that while QTWebKit had fun with flash integration, Qt WebEngine will probably make Flash integration impossible. The worst part (at least for where I work) of using Flash in QtWebView was the non-availability of a license to just include the flash .dll in our application distribution.
  - nicholassmith 13y ago
    I thought whilst Chromium didn't get the closed source bits, they were getting access through PPAPI, as everything else was on NPAPI and Adobe & Google decided to shift off it? I could be wrong though it's been a while since I last looked into it, and there was a lot of he-said-she-said on email lists about it at that point.
  - teho 13y ago
    >Since Chromium doesn't support flash (that is one of the closed source bits added to Chrome) The Chrome PPAPI Flash Player works perfectly on Chromium and the binary can be shipped separately.
    - azakai 13y ago
      In principle, but does Adobe ship the Flash PPAPI binary separately?
      - gcr 13y ago
        How do other WebKit-based browsers like Luakit get flash to work? I thought they were always using the NS Plugin API for Flash. Is that being deprecated; is PPAPI a replacement?
        gsnedders 13y ago
        Adobe no longer support (except for security updates) the NPAPI (not NSAPI) plugin on Linux, which also has a habit of crashing a lot and randomly hanging… If you want Flash to work under Linux, one practically has to use the PPAPI plugin. Note nobody except Chrome (and those based on the Chromium Content API) has any plan to support PPAPI, so in that sense NPAPI is alive and strong.
borplk 13y ago
Can someone provide a simplified summary?
- Touche 13y ago
  Qt is switching (from WebKit) to Chromium.
- hannibal5 13y ago
  The Qt WebEngine will be based on Chromium.
- leokun 13y ago
  Qt is making a change to what iOS/Cocoa, Android, and Microsoft developers call a 'webview', an embedded browser engine. Qt's version of a webview will switch from WebEngine to Chromium. So if you want to render a browser page inside an application built with Qt, in the future this page it will use Chromium's engine, not WebEngine which was a homegrown engine based on webkit.
  - raptium 13y ago
    Qt WebEngine is (the new one) based on Chromium. The one based on WebKit is just called Qt WebKit.
    - leokun 13y ago
      Yes my mistake, thanks!
- icefox 13y ago
  After Google forked WebKit a few months ago into the Blink project the Qt trolls got together and decided that they will basing the future Qt WebKit module on the Google fork of WebKit and not the (Apple maintained) WebKit. While similar the two differ in a few key aspects the main one being if the WebKit/Blink webviews are in process or out of process (ignoring the discussion complication of webkit2). There were various other reason for following Blink and honestly the day Blink came out I would be shocked if there hadn't been meetings in every company contributing to WebKit putting together a mini-project to decide if they should follow Google. There were a lot of little pain points in the WebKit project and Google in one swoop cleaned up a ton of them. If anything I see WebKit as an example of failing to steward an open source project on the part of Apple or the community as a whole. Everyone was working on their own problems that it was hard to get movement to fix bigger problems that applied to all ports. Even very visible things like letting each port have their own build system sounded good originally, but was one of the things holding the project back. I was on the edge of the community (worked on the qtwebkit port, helped port chrome to linux, ce port, blackberry port, etc) so I know only so much, but it would be interesting to hear from someone closer in the community not about what was bad technically in the project, but how as an project we (socially?) didn't fix them. Why didn't the WebKit meetings fix this? Did Apple have too much say because they owned the svn server to the detriment of themselves?
thesorrow 13y ago
What's going to happen to wkhtmltopdf and phantomjs ?
- denysonique 13y ago
  Their future releases may be based on Qt::WebEngine instead of Qt::WebKit
orng 13y ago
This is great news, although I really wish it would have come sooner as we have spent a significant amount of time getting Chromium Embedded Framework (CEF) to play nice with our Qt application in the past months. One thing that I wonder though: Does this mean that the Qt WebEngine will stay more up to date? Because the old QtWebkit was lagging pretty far behind and for instance didn't get HTML5 support until very recently.
- sspiff 13y ago
  While it's bad for you - you had to spend a lot of time and effort on integrating - perhaps this experience can be shared with the Qt WebEngine people and improve their effort?
rolleiflex 13y ago
This is excellent news. I have been working on a project that uses QtWebkit extensively and I have had my fair share of burns from QtWebkit's platform specific quirks—such as all rendering being retina except SVG, causing SVG's in webpage to show incredibly pixelated. Chromium core should enforce a stricter feature parity with the current Chrome.
passfree 13y ago
This is what happens when Mozilla stopped giving shit about their XUL platform.
- shmerl 13y ago
  Though I disagree with them on this: > Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available. I think Firefox moves better. Plus Mozilla innovates more with their Servo project. Though I wish Mozilla would support projects like these officially instead of ignoring them: https://wiki.mozilla.org/Embedding/IPCLiteAPI https://wiki.mozilla.org/Embedding/IPCLiteAPI That's what is used for Jolla's browser in the upcoming Sailfish (it uses Qt for the UI with that IPC embedding).
- randallu 13y ago
  What about WebKit! Now they're down to Apple, GTK+, EFL and BlackBerry (until they go bankrupt). EFL is funded by Intel and Samsung for Tizen (insurance policy against Android?). GTK+ is supported by consulting and occasional grants. If everyone but Apple leave WebKit will it stay open?
  - fpgeek 13y ago
    The LGPL means there will still be code dumps, but the development process has been closing for some time (e.g. WebKit2 process changes).
rwbt 13y ago
A little bit off topic, but I'm glad Qt didn't end up at Microsoft.
- shmerl 13y ago
  +1000. That could be a disaster. Some people in Nokia really saved it before the rest of Nokia sunk.
  - general_failure 13y ago
    Nobody saved it. It just got sold off.
    - shmerl 13y ago
      Selling off could hurt the project. Here it helped.
bla2 13y ago
Posted by Lars Knoll, author of KHTML (which was then forked to become WebKit): http://en.wikipedia.org/wiki/KHTML http://en.wikipedia.org/wiki/KHTML
fauigerzigerk 13y ago
So, if I understand this correctly, there will be no more direct access to the DOM via C++, and JavaScript will be the only language for fine grained, fast DOM access. I'm not entirely happy about that, although I do understand the benefits of the new multi-process architecture.
- aboodman 13y ago
  Chrome supports a single process mode [1], and has in-process APIs [2] for manipulating the DOM via C++. I would be surprised if it wasn't already possible to make use of these from the embedder side if you're in single-process mode. But if it's not, I wouldn't expect there to be pushback on changes to that effect. [1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/content_switches.cc&sq=package:chromium&l=746 https://code.google.com/p/chromium/codesearch#chromium/src/c... [2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/public/web/WebElement.h&sq=package:chromium https://code.google.com/p/chromium/codesearch#chromium/src/t...
dave1010uk 13y ago
Everyone seems to be moving from WebKit to Blink/Chromium. I wonder if / when Apple will be the only one using WebKit? Slightly off topic: are there any desktop browsers that run on Linux or Windows that run an up to date version of webkit (for browser testing)?
- jarek-foksa 13y ago
  You could try compiling MiniBrowser which is bundled with WebKit-GTK tarball.
- icefox 13y ago
  Well as long as you have a copy of Arora that links to a current Qt you will have a recent WebKit. I have put Arora as a project on ice, but it is still useful for that purpose.
fulafel 13y ago
If you ship a copy of a browser engine you need to make sure deployments are diligently kept up to date via patches, that didn't hapapen with the earlier Qt setup. Hope they have a plan for it now.

106 points by ddb 13y ago

This is really interesting, because whilst Qt Webkit was a fantastic effort it had some quirks. Last project I was working on used Qt Webkit to provide a basic browser, so there was lots of fun with flash player integration, Javascript going awry and so on, if they're relying on Chromium to act as the core it should remove a lot of those headaches for developers and allow them to build on top of it much easier. Definitely a big change, quite exciting though.

jdboyd 13y ago
Since Chromium doesn't support flash (that is one of the closed source bits added to Chrome), I suspect that while QTWebKit had fun with flash integration, Qt WebEngine will probably make Flash integration impossible. The worst part (at least for where I work) of using Flash in QtWebView was the non-availability of a license to just include the flash .dll in our application distribution.
- nicholassmith 13y ago
  I thought whilst Chromium didn't get the closed source bits, they were getting access through PPAPI, as everything else was on NPAPI and Adobe & Google decided to shift off it? I could be wrong though it's been a while since I last looked into it, and there was a lot of he-said-she-said on email lists about it at that point.
- teho 13y ago
  >Since Chromium doesn't support flash (that is one of the closed source bits added to Chrome) The Chrome PPAPI Flash Player works perfectly on Chromium and the binary can be shipped separately.
  - azakai 13y ago
    In principle, but does Adobe ship the Flash PPAPI binary separately?
    - gcr 13y ago
      How do other WebKit-based browsers like Luakit get flash to work? I thought they were always using the NS Plugin API for Flash. Is that being deprecated; is PPAPI a replacement?
      - gsnedders 13y ago
        Adobe no longer support (except for security updates) the NPAPI (not NSAPI) plugin on Linux, which also has a habit of crashing a lot and randomly hanging… If you want Flash to work under Linux, one practically has to use the PPAPI plugin. Note nobody except Chrome (and those based on the Chromium Content API) has any plan to support PPAPI, so in that sense NPAPI is alive and strong.

borplk 13y ago

Can someone provide a simplified summary?

Touche 13y ago
Qt is switching (from WebKit) to Chromium.
hannibal5 13y ago
The Qt WebEngine will be based on Chromium.
leokun 13y ago
Qt is making a change to what iOS/Cocoa, Android, and Microsoft developers call a 'webview', an embedded browser engine. Qt's version of a webview will switch from WebEngine to Chromium. So if you want to render a browser page inside an application built with Qt, in the future this page it will use Chromium's engine, not WebEngine which was a homegrown engine based on webkit.
- raptium 13y ago
  Qt WebEngine is (the new one) based on Chromium. The one based on WebKit is just called Qt WebKit.
  - leokun 13y ago
    Yes my mistake, thanks!
icefox 13y ago
After Google forked WebKit a few months ago into the Blink project the Qt trolls got together and decided that they will basing the future Qt WebKit module on the Google fork of WebKit and not the (Apple maintained) WebKit. While similar the two differ in a few key aspects the main one being if the WebKit/Blink webviews are in process or out of process (ignoring the discussion complication of webkit2). There were various other reason for following Blink and honestly the day Blink came out I would be shocked if there hadn't been meetings in every company contributing to WebKit putting together a mini-project to decide if they should follow Google. There were a lot of little pain points in the WebKit project and Google in one swoop cleaned up a ton of them. If anything I see WebKit as an example of failing to steward an open source project on the part of Apple or the community as a whole. Everyone was working on their own problems that it was hard to get movement to fix bigger problems that applied to all ports. Even very visible things like letting each port have their own build system sounded good originally, but was one of the things holding the project back. I was on the edge of the community (worked on the qtwebkit port, helped port chrome to linux, ce port, blackberry port, etc) so I know only so much, but it would be interesting to hear from someone closer in the community not about what was bad technically in the project, but how as an project we (socially?) didn't fix them. Why didn't the WebKit meetings fix this? Did Apple have too much say because they owned the svn server to the detriment of themselves?

thesorrow 13y ago

What's going to happen to wkhtmltopdf and phantomjs ?

denysonique 13y ago
Their future releases may be based on Qt::WebEngine instead of Qt::WebKit

orng 13y ago

This is great news, although I really wish it would have come sooner as we have spent a significant amount of time getting Chromium Embedded Framework (CEF) to play nice with our Qt application in the past months. One thing that I wonder though: Does this mean that the Qt WebEngine will stay more up to date? Because the old QtWebkit was lagging pretty far behind and for instance didn't get HTML5 support until very recently.

sspiff 13y ago
While it's bad for you - you had to spend a lot of time and effort on integrating - perhaps this experience can be shared with the Qt WebEngine people and improve their effort?

rolleiflex 13y ago

This is excellent news. I have been working on a project that uses QtWebkit extensively and I have had my fair share of burns from QtWebkit's platform specific quirks—such as all rendering being retina except SVG, causing SVG's in webpage to show incredibly pixelated. Chromium core should enforce a stricter feature parity with the current Chrome.

passfree 13y ago

This is what happens when Mozilla stopped giving shit about their XUL platform.

shmerl 13y ago
Though I disagree with them on this: > Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available. I think Firefox moves better. Plus Mozilla innovates more with their Servo project. Though I wish Mozilla would support projects like these officially instead of ignoring them: https://wiki.mozilla.org/Embedding/IPCLiteAPI https://wiki.mozilla.org/Embedding/IPCLiteAPI That's what is used for Jolla's browser in the upcoming Sailfish (it uses Qt for the UI with that IPC embedding).
randallu 13y ago
What about WebKit! Now they're down to Apple, GTK+, EFL and BlackBerry (until they go bankrupt). EFL is funded by Intel and Samsung for Tizen (insurance policy against Android?). GTK+ is supported by consulting and occasional grants. If everyone but Apple leave WebKit will it stay open?
- fpgeek 13y ago
  The LGPL means there will still be code dumps, but the development process has been closing for some time (e.g. WebKit2 process changes).

rwbt 13y ago

A little bit off topic, but I'm glad Qt didn't end up at Microsoft.

shmerl 13y ago
+1000. That could be a disaster. Some people in Nokia really saved it before the rest of Nokia sunk.
- general_failure 13y ago
  Nobody saved it. It just got sold off.
  - shmerl 13y ago
    Selling off could hurt the project. Here it helped.

bla2 13y ago

Posted by Lars Knoll, author of KHTML (which was then forked to become WebKit): http://en.wikipedia.org/wiki/KHTML http://en.wikipedia.org/wiki/KHTML

fauigerzigerk 13y ago

So, if I understand this correctly, there will be no more direct access to the DOM via C++, and JavaScript will be the only language for fine grained, fast DOM access. I'm not entirely happy about that, although I do understand the benefits of the new multi-process architecture.

aboodman 13y ago
Chrome supports a single process mode [1], and has in-process APIs [2] for manipulating the DOM via C++. I would be surprised if it wasn't already possible to make use of these from the embedder side if you're in single-process mode. But if it's not, I wouldn't expect there to be pushback on changes to that effect. [1] https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/content_switches.cc&sq=package:chromium&l=746 https://code.google.com/p/chromium/codesearch#chromium/src/c... [2] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/public/web/WebElement.h&sq=package:chromium https://code.google.com/p/chromium/codesearch#chromium/src/t...

dave1010uk 13y ago

Everyone seems to be moving from WebKit to Blink/Chromium. I wonder if / when Apple will be the only one using WebKit? Slightly off topic: are there any desktop browsers that run on Linux or Windows that run an up to date version of webkit (for browser testing)?

jarek-foksa 13y ago
You could try compiling MiniBrowser which is bundled with WebKit-GTK tarball.
icefox 13y ago
Well as long as you have a copy of Arora that links to a current Qt you will have a recent WebKit. I have put Arora as a project on ice, but it is still useful for that purpose.

fulafel 13y ago

If you ship a copy of a browser engine you need to make sure deployments are diligently kept up to date via patches, that didn't hapapen with the earlier Qt setup. Hope they have a plan for it now.