Experimenting with Chromium™ and Qt

Published Tuesday June 25th, 2013 | by

Chromium is the open source project that powers the Chrome browser. It is not only an HTML renderer, but it also comes with a complete implementation of the web platform – from the network stack up to the multimedia framework.
Just like Qt, it is available on multiple desktop and mobile platforms. So what if Qt developers want to make use of it in the universe of Qt?

Well, for the past few weeks we have actually been busy experimenting with exactly that.
Today we would like to present the prototype of our work, that demonstrates the integration of Chromium into QtQuick2 and Widgets.

Cross platform support was not the main focus for this prototype though. Instead we tried to keep our changes to Chromium to a minimum.
This is why we are using gyp and ninja as a build system for this project – nicely wrapped in a qmake project.

Just try it out for yourself, and send us feedback. To build and run the examples simply follow the instructions below.
However, keep in mind that this is currently only a prototype for the sake of experimenting. There is no stable API and no promise of future support.

Get the sources and build the prototype

To be able to build and run the prototype you must have a recent build of Qt5 (v5.1.0-rc1).
Installing the build dependencies on Ubuntu:

sudo apt-get build-dep chromium-browser

Install the Chromium depot_tools and fetch the Chromium sources (this might take a while):

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=$PWD/depot_tools:$PATH
fetch chromium --nosvn=True
export CHROMIUM_SRC_DIR=$PWD/src

Clone the QtWebEngine repository and apply our Chromium patches:

git clone git://gitorious.org/qt-labs/qtwebengine.git
./qtwebengine/patches/patch-chromium.sh

Build QtWebEngine:

cd qtwebengine && qmake && make

Running the examples

The QtWebEngine repository contains two example applications. One of them uses QtQuick2 and the other one uses Widgets. The examples are very simplistic web browsers using a Chromium based webview.
Both implementations can be found in the examples subdirectory and can be executed from the command line.

Known limitations:

  • Currently the only platform supported by the prototype is Linux/X11.
  • There is no integration with QNetworkAccessManager.

Chromium is a trademark of Google Inc.

Did you like this? Share it:

Posted in Internet, Labs, Network, Qt Quick 2, Uncategorized

38 comments to Experimenting with Chromium™ and Qt

Nice work guys! This is very cool!

Kurt says:

And how many additional dependencies does that carry?
You guys are currently absolutely incapable of making QtWebKit a proper rendering engine with swift security updates and now you want to “research” adding yet another rendering engine into the mix?
I know you do that because Canonical wants this for Ubuntu Touch. It’s public information. No need to not confirm it.

Instead of adding layers upon layers just to follow Google, better get your act together and work with the WebKit-GTK and WebKit-EFL people to create a stable branch of WebKit with monthly bugfix releases and yearly feature releases.

Donald says:

@Zeno @Simon and @friends

Wicked; really nice to see.

@Kurt

You sir are a schmuck. The Qt Webkit team is tiny; the Chromium team is immense. Why the hell would they contribute to dead-end webkit forks when they can harness Chrome/Blink. You are a cabbage and I am a muppet for ever acknowledging your dim witted putzery.

Num83rGuy says:

You… You, I like

AC says:

Donald, you’re probably right and everything, but I don’t find your language appropriate. Kurt is expressing his expectations as a user. He may lack context and lots of info available to Qt devs, still he has the right to express his impossible wishes. You should rather explain why he’s wrong and things cannot be done the way he’d like to.

David Johnson says:

So basically Donald is saying that QWebkit and QNetworkAccessManager is dead, and that we need to start living in Google’s world.

Donald says:

@David

No, what Donald is saying is that Chrome is an immense, fast moving web engine. The Chrome team is a damn sight bigger than the Qt team. Pick your fights selectively; I am not advocating a Opera-esque tossing away of everything that defines self, or admitting defeat. Harness that turkey.

@AC

I am sorry if my language offends you; I am just another obnoxious user/jerk espousing his opinions regarding a technology he feels emotionally attached to.

João Barbosa says:

What is the purpose of this since Qt has WebKit?

Zeno Albisser says:

@João Barbosa: As stated in the blog post, Chromium is more than just a rendering engine. So with this prototype we are trying to figure out how much of Chromium we can actually reuse without major changes, and if we can make use of Chromium’s strengths within Qt applications.

vrm says:

would it be possible to write an API wrapper to bridge the GTK and Qt toolkit implementations so that any GTK application can seamlessly run in the Qt world as a Qt application? Similar to the gtk qt style wrapper but wrapping the all the symbols for a particular API version of GTK.

Lilian says:

I’ve seen a lot of game launchers using Qt specifically for the web frame, so, I guess that’s good…

Richard Moore says:

@Zeno Albisser

Given that it’s the stated intent of the blink project to perform deeper integration between the various layers such as the network stack and the rendering engine over time, I’d question if the things you can reuse now will be possible in a few months or years time. My understanding is that the idea is that you’d use the chromium embedded framework as a whole, including the network stack etc. rather than cherry picking parts of it.

Zeno Albisser says:

@Richard Moore: You are probably right, as this is exactly what i am saying. ;)
We are avoiding major changes to Chromium itself. We are taking it pretty much the way it is, and hook it up to Qt.

Sergio Correia says:

@Zeno: are you looking at replacing QtWebKit with such a project, eventually, assuming your experimenting goes “well”?

Zeno Albisser says:

@Sergio: Currently this is only a research project. So it is all about finding out, what is actually possible. Where to go from there, is something we will have to look at once we know the outcome from the prototyping efforts.

Richard says:

There has to be a reason why this is being attempted, what kind of outcome are you guys hoping for?

Zeno Albisser says:

@Richard: So there we have the IMHO best toolkit and the IMHO most complete implementation of the web platform. Why should we not try to use both of them together?

Kurt says:

Because QtWebKit is fine without adding countless additional Chromium dependencies to Qt. All QtWebKit lacks is proper release management. Just work with the other WebKit contributors to create a stable branch and release regular bugfixes off that branch.
It’s not rocket science.

Turk says:

The Qt team has to choose sides – webkit or blink. This is just exploring the blink path. Apple has been openly hostile about contributing to webkit2, so chromium is a strong contender as replacement.

Deedo says:

WebKit is missing a lot of features for example on Windows (lack of proper video) and even Linux (webgl requires special hw surface class they say on IRC). Maybe these things work better in Chromium when Google implemented them, although not using Qt.

Kurt says:

Google actively refused to contribute Chrome’s multi-process architecture to WebKit and now Apple is the hostile one… right…
Code must go though review in WebKit, just as in every other sane software project – including Chromium.

The failure to set up proper release management and cooperation with other WebKit contributors is Digia’s fault. Simply switching to Chromium, hoping that Google will magically fix that failure is a flawed assumption. Digia did not manage to make monthly bugfix releases of a stable WebKit despite the fact that Apple openly manages stable WebKit branches for Safari: https://trac.webkit.org/browser/branches/safari-537-branch/Source
Why should a possible “QtBlink” be any different?

QtWebKit is cool because it’s relatively lightweight. Looking just at package sizes, WebKit is about 30MB in size. Chromium is almost 140MB.
Additional 100MB just to drink Google’s Cool Aid? I’m not convinced…

Adenilson Cavalcanti says:

Zeno

Quite interesting!

Adenilson

mojorison says:

Hi guys, nice work !

I failed to build on Fedora x86_64:


[...]
/usr/local/src/depot_tools/ninja -C /usr/local/src/qtwebengine/out/Release
ninja: Entering directory `/usr/local/src/qtwebengine/out/Release'
[2/11] LINK QtWebEngineProcess
FAILED: g++ -Wl,-z,now [...] -ludev
/opt/Qt5.1.0/5.1.0-rc1/gcc_64: file not recognized: Is a directory
collect2: erreur: ld a retourné 1 code d'état d'exécution
[2/11] ACTION Qt5WebEngine: moc_web_contents_delegate_qt.cpp_892d1f5dc7da17f6f781dfafa5e4c259
ninja: build stopped: subcommand failed.
make[1]: *** [ninja] Erreur 1
make[1] : on quitte le répertoire « /usr/local/src/qtwebengine/build »
make: *** [sub-build-make_first-ordered] Erreur 2

Have you got any idea about this issue ?

[...] : Experimenting with Chromium™ and Qt. Sources de QtWebEngine. Ce contenu a été publié dans Qt par dourouc05. Mettez-le en favori [...]

Youssef says:

This is nice, I can see the benifits of having chromium’s engine in Qt :D

Björn says:

I hope it will be more than Xulrunner with Qt. But a Firefox with Qt instead of Xulrunner would be nice too.
Same for {Libre,Open}office and VCL.

Dasun says:

Fantastic. Excited to see it on all platform. Hope it will never abandoned !

Num83rGuy says:

@Kurt

Loosen that sphincter a bit man. This is just an experiment. They haven’t announced Google-KDE© yet.
All software has adviantages and disadvantiages. Just checking those out, ok? Yes, we have a wheel but, it’s big and kinda square on one side. Let’s try this other wheel it’s lumpy in a different place and way.

gremwell says:

The Chromium Embedded Framework (CEF) already takes some of the interfacing pain out – can this be reused? It also provides an API using delegates where you can intercept things like HTTP requests before they go out and hit the network, and take action.

The webkit1 API is fantastic. webkit2 api is… non-existant?

Is it even POSSIBLE to put CEF into QtQuick2?

Zeno Albisser says:

@gremwell: We do not believe that CEF is the layer we want to interface with. We are rather looking at the level of the content API.
Chromium has it’s own multi process architecture, so it does not use WebKit2.

Eugene says:

AWSOME thing, Google is a good contributor, so chromium is a good chose better than webkit. All sites oriented firstly on chrome, than on other browsers. So best rendering be in chromium. But u need to integrate more deeper… our company need good support of features like clicking on QWebElement directly without things like javascript… for creating automated tests for web sites.

gremwell says:

@Zeno
(Webkit != chromium) == understood (and blink very soon I believe)

Just expressing the desire for programmable API which is more than just navigation to URLs. Having an API where we can integrate with the javascript (ala Webkit 1) is really useful.

I believe @Eugene is expressing the same desire. i.e. Deeper integration with Qt than just plain ol’ navigation and display stuff.

M.S. Babaei says:

Good to see big things are happening in QtWorld.

Zeno Albisser says:

@gremwell & @Eugene: We are well aware of that desire. And I think we will address that issue at the appropriate time. However, as we are at a very early stage of this project we will probably not be able to look into that immediately.

Eugene says:

Projects that needs to show more then plain webpage needs deeper integration. If you release features that be in plans for webkit(emulate click by sending click event directly to webelement) thats will be awsome, and have nice push for projects like https://github.com/thoughtbot/capybara-webkit

AcerExtensa says:

Very interesting project for me. Will try it today! Any plans to make it possible to build on Windows platforms? With MinGW for example?

Zoltan Arvai says:

It seem only qtwebengine.git step is required now. The new init-repository script takes care on cloning and patching chromium :-)

git clone git://gitorious.org/qt-labs/qtwebengine.git
cd qtwebengine
./init-repository.py
qmake && make

J says:

With support for QNetworkAccessManager added, this would be perfect for pretty much all of my existing hybrid applications. QtWebKit is nice, but there are still a few HTML5 features that are rough around the edges that I really -need- to use, and Chromium has polished versions of said features.

I’m going to try the repo and run a few tests, but to really exercise it, I’ll need to be able to set the QNetworkAccessManager instance used, which means that it will need to use QNetworkAccessManager for network access instead of the typical Chromium way. I’d imagine that I’m not the only one in this situation.

Other than here, is there anyway to track or suggest a direction of your progress?

Commenting closed.