Version 11 (modified by, 16 years ago) (diff)

Add link to HackingGtk

Building the Gtk port

The Gtk port of WebKit is intended to provide a browser component primarily for users of the portable Gtk+ UI toolkit on platforms like Linux.

Status of the port

The port is actively maintained, and its build state is continuously tested by the WebKit build-bot.

Developers interested in using or contributing to the Gtk port should be willing to get their hands dirty at this stage. Patches are welcomed on the bug tracker and help is readily available on the IRC channel and mailing list for developers who want to learn the ropes.

It is worth noting that this project is being developed directly in WebKit SVN and is entirely unrelated to the classic Gtk+ WebCore.


The code should be easily built on any Linux distribution which has development packages for Gtk+ installed. Packages you might need to install (in addition to an "ordinary build environment"):

  • libicu-dev
  • libxslt-dev
  • libcurl-dev
  • libsqlite3-dev
  • libjpeg62-dev
  • libpng12-dev
  • gperf
  • bison
  • flex version 2.5.33 or later

If you forgot to install one of the build dependencies, your build tree might be in a bad state and might fail to compile even after you've installed the missing dependency. In this case, you should ensure your SVN checkout is entirely clean with eg. make -C WebKitBuild/Release/WebCore clean

Using Qmake4

The Gtk port has made a compromise on its build system by incurring a dependency on qmake 4, the Qt toolkit build system. This is only a build-time dependency -- the compiled executables will of course continue to have no requirement of Qt. The decision was made to share resources with the Qt porting team and has been largely successful -- the Gtk port is more likely now than ever to be in a building state straight out of SVN while the port developers have more free time to write code instead of maintaining the old Bakefile build system.

To start the build, ensure that you have qmake4 installed and run:

WebKit/WebKitTools/Scripts$ ./build-webkit --gtk

The above command will try to execute "qmake". If your qmake4 binary is named differently, e.g. on Debian, use the --qmake= option.

WebKit/WebKitTools/Scripts$ ./build-webkit --gtk --qmake=qmake-qt4

This will build both the library and the GtkLauncher demo in WebKit/WebKitBuild

Note: your system might have both qmake and qmake-qt4 (Debian). You must use qmake-qt4. Using qmake fails to compile WebCore/platform/gtk/gtk2drawing.c (missing header gtk/gtk.h)

Building qmake if your distribution doesn't ship it in a package

 tar -xvzf qtopia-core-opensource-src-4.3.2.tar.gz
 cd qtopia-core-opensource-src-4.3.2
 echo yes | ./configure -fast

Et voila the bin/ directory holds a qmake binary you can use for the Gtk+ port. You might want to set the QMAKESPEC to $PWD/mkspecs/ANY-SPEC-YOU-WANT but the default should just work.


To install the library and the header files:

$ cd WebKitBuild/Release

# make install


See the hacker's guide to WebKit/GTK+.

Code layout

The GTK+ port targets the cross-platform GLib and GTK+ APIs. This means that it can be built against any of the windowing systems supported by GTK+ and Cairo without modification -- those tested so far are X11 and DirectFB. Windows should work too, possibly needing a couple of tweaks.

This means that developers adding code specific to a certain windowing system should make sure their changes are conditionally compiled only when that windowing system is available. This might be done at configure time or with a switch passed to the build system, or even just using the definitions provided by the gdk headers.

The main components of the port:

Gtk+-specific modules

There may be other gtk-port related directories which have yet to be listed here.

Shared code modules

While the Gtk+ port is the primary consumer of these backends, we aim to keep them portable, avoiding even ifdef'd sections specific to the Gtk+ port:

Current tasks (July '07)

  • Make things work with debugging enabled (when NDEBUG is removed, assertions are triggered right now)
  • Fix animated GIF images -- consider using GdkPixbuf?
  • Continue to fix the curl backend
  • Start to consider consolidating the widget into a single place as the Qt port has done, and look into implementing eg. createFrame()
  • Look into supporting the canvas
  • Attempt to merge the Cairo code in the Win32 port -- the equivalent code is copy-and-pasted into the "Gdk" port in some places. This will help reduce code duplication but also help towards getting WebKit/Gdk/Gtk+ working on Windows

Issues known


  • Review and possibly integrate the sand-labs CURL backend code. It has a slightly different API, so needs to be back-ported, but looks like it may be more feature-complete, able to handle redirects properly etc.
  • The non zero select timeout feels bad. Make it possible to write a GSourceFunc to not poll the sockets and have a timeout: This can probably be done by integrating code from MIT/X11 licensed glibcurl.
  • Cookie handling is completely lacking as pointed out on the mailing list
  • Errors of curl need to be properly populated


  • A lot of classes are not yet implemented
  • For painting we have some issues in regard to Expose Events and when WebKit will call paint.


  • Consider taking code directly from Mozilla's LGPL licensed Gtk+ theming backend. They deal with a lot of corner cases which don't look fun to re-implement.
  • Focus ring drawing
  • Scrollbars for PlatformScrollbar will be terrible as we need to implement a HitTest but don't know where the elements of the scrollbar hide
  • Native theming for text entries
  • Find a way to draw a GtkComboBox, at least the button part. This is needed to implement theming of the <select> element properly.


  • Missing dependencies are not reported and force a user to take a closer look at the screen.