

Introducing the Qt WebEngine - ddb
http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/

======
bla2
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)

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

~~~
shmerl
+1000. That could be a disaster. Some people in Nokia really saved it before
the rest of Nokia sunk.

~~~
general_failure
Nobody saved it. It just got sold off.

~~~
shmerl
Selling off could hurt the project. Here it helped.

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

~~~
teho
>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
In principle, but does Adobe ship the Flash PPAPI binary separately?

~~~
gcr
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
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.

------
dave1010uk
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)?

~~~
icefox
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.

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

------
borplk
Can someone provide a simplified summary?

~~~
icefox
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?

~~~
Aldo_MX
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.

------
fauigerzigerk
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
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/c...](https://code.google.com/p/chromium/codesearch#chromium/src/content/public/common/content_switches.cc&sq=package:chromium&l=746)

[2]
[https://code.google.com/p/chromium/codesearch#chromium/src/t...](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/public/web/WebElement.h&sq=package:chromium)

------
orng
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
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?

------
thesorrow
What's going to happen to wkhtmltopdf and phantomjs ?

~~~
denysonique
Their future releases may be based on Qt::WebEngine instead of Qt::WebKit

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

~~~
randallu
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
The LGPL means there will still be code dumps, but the development process has
been closing for some time (e.g. WebKit2 process changes).

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

