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.
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.
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?
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.
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.
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.
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.
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?
A little offtopic, but I wanted to clarify to people not familiar with Qt, that the term "Qt trolls" is because the company behind Qt was called Trolltech, before Nokia purchased it.
Didn't google introduce at least some of those "little pain points" due to their requirement for alternate js engine (for v8), and their own process sandbox?
I heard that after the fork, both sides were able to clean up and remove a ton of code (thus benefiting pretty much everyone).
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.
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.
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.
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.
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?
> 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:
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?
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.
