Installing and Running WebKit in Linux Using Qt
Published 8 years 4 months ago on April 23, 2007 — 6 min read
I’m coming to appreciate more and more all of the hard work software developers perform. I wouldn’t consider myself an open source elitist, but there’s something special about the associated ideologies. When a large community of people band together to work on a project, a lot of fantastic products can be created.
One such product is WebKit, the open source Web browser rendering engine used by Safari (as well as a number of other products). It’s very important to keep in mind that Safari and WebKit are two very different things. Safari is a Web browser that uses WebKit as it’s rendering engine.
The WebKit developers put forth the effort to port WebKit to Qt, which is, as stated by the developers:
Qt is a comprehensive development framework that includes an extensive array of features, capabilities and tools that enable development of high-performance, cross-platform rich-client and server-side applications.
Qt is truly cross-platform and allows deployment on a wide range of hardware configurations, as opposed to other “cross-platform” products that are restricted to Windows and Mac OS X. The fact that the WebKit developers put forth the effort of porting to Qt4 gives users the ability to run their rendering engine on any platform. Thanks to their hard work, it’s quite easy to run a WebKit-based browser in Linux.
Preparing your Linux system for WebKit
I’d like to be explicit in saying that the following instructions are geared towards a fresh install of Ubuntu 7.04, but should be applicable to a wide variety of Linux distributions. First and foremost you’ll need to add extra repositories. After you have followed those steps we can begin.
There are a number of packages you’ll need to successfully build a Qt4 Web browser that uses WebKit.
sudo apt-get install libqt4-dev libxslt-dev gperf bison libsqlite3-dev flex build-essential subversion
There will be a lot of additional packages to install, so don’t be surprised if the list of packages for installation is significantly large.
Obtaining a nightly build of WebKit
Next, we’ll need to use Subversion to check out the WebKit source. The following command will check out files to a folder titled
WebKit within your working directory, so be sure your working directory is appropriate (I used my
svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit
You will be able to monitor the checkout process as each file is listed in your terminal.
The checkout will take some time, as there are quite a few files to download. When the checkout is complete, you’ll see the following message:
Building your Qt4 WebKit browser
When the checkout is complete, you can initiate the build of your Qt4 WebKit browser using the following command:
The script will take a minute to prepare the build, and then the process will begin.
This step can take quite a bit of time depending on your hardware configuration, so take a few minutes to have a cup of coffee and relax while your browser is being built. Your terminal will scroll with hundreds of lines of build commands and more, so don’t feel the need to sit and watch it build (unless you’re interested — I was).
When your build is complete, you’ll see the following message:
Running the browser
A successful build means you can run your Qt4 WebKit browser using the following command:
A very basic browser window will appear with limited controls and an address bar. There will be some information scrolling in your terminal, but it can generally be disregarded.
You’ve now got a native WebKit browser to play around with in Linux. I took a second to attach the launch command to an entry in an panel using the WebKit icon. It’s more convenient than keeping the command saved somewhere to copy and paste when I’d like to test in WebKit.
You can also add your WebKit browser as an entry in your Applications menu using the menu editor if you prefer.
Some quirks I’ve come across so far
There are a few things that will appear out of place. First and foremost, you’ll notice that form inputs will have, what seem to be, a random
background-color. I may be completely mistaken, but I haven’t looked into things deep enough to find the rhyme or reason behind the discrepancy. From what I can tell, if the
input is styled with CSS, the style takes precedence over any ‘default’ colorization.
The next issue I’ve come across is that you’re not able to work with
xHttpRequest. This is another issue I have not researched in enough detail, but if anyone has any insight regarding an inability to make use of XHR, I’d be interested in reading about it.
Finally, the only other quirk I’ve come across so far is that you’ll need to include
http:// in any URL you enter in the address bar. While this may seem like a small detail to write about, after my first successful build I spent a few minutes thinking that something went wrong.
Things to keep in mind
Perhaps the most important thing to keep in mind is that you’re running a nightly build of WebKit, not the build Safari is using. The nightly versions are much more advanced than Safari’s WebKit, so some of the quirks that appear in Safari may be handled in your Qt4 browser.
Due to the version discrepancy, you can’t depend on a nightly build of WebKit sufficing for a legitimate test in Safari. It is useful, however, to take a quick look at overall structural elements of your designs before making the effort of moving to an OS X machine.
Footnotes and inspiration
I was originally drawn to working with WebKit on Linux by a post on the same subject at as days pass by. I had followed his instructions and ran into a few issues. Going on his advice, I joined
irc.freenode.net and started discussing a few issues with one of the developers there. He (or she) was extremely helpful in assisting me to successfully build WebKit. I was also directed to a Wiki page which included similar instructions to the post on as days pass by. I felt compelled to write this post based on specific instructions surrounding Ubuntu Feisty but would like to give much credit to the hard work of others.