WebKit/GTK+ API design

In the last month, we’ve started to look more seriously at the WebKit public API and how it fits with GLib/GTK+ principles. Some of the fixes have been obvious:

  • #16174: Use “URI” not “URL” in public API
  • #15691: The main widget should be called WebView, not Page

Policy changes have been made to ensure consistency:

  • Any public entry point, property or signal that does not match GTK+ conventions is now considered a Major bug alongside security issues and crashers (with some exceptions like the new portable JavaScript engine C API (#15687) — more on this in my next post.)
  • Any new API contributions without corresponding GTK-Doc documentation will be rejected. Enough said.

The Hacker’s guide to WebKit/GTK+ now covers topics such as API design, patch contribution and optimisation (including Cairo/SVG/canvas performance and memory reduction).

Sources of inspiration


GtkTextView has a solid design and well-understood data model thanks to its heritage, being a synthesis of the venerable Tk text widget. Some applications like Tomboy are starting to push the limits of GtkTextView as they look towards integrating rich media and Web content synchronisation.


  • Can we provide a GtkTextIter implementation that works with the W3C DOM (and our upcoming GObject DOM binding), or is the concept of GtkTextTags too limiting to make this worthwhile?
  • How faithfully can we bridge between Markup and HTML?

GtkMozEmbed is a thin binding around a stable and mature browser engine, Gecko. The primary consumers here are Epiphany, Devhelp and Yelp. To make serious use of the underlying engine, these applications have to resort to C++ and Gecko’s internal APIs which can be inconvenient.

GtkMozEmbed seems to be awkward on non-X backends since it just uses the Mozilla port for that platform, not a GTK+ backend. WebKit/GTK+ on the other hand supports all GTK+ backends natively including DirectFB, OS X and Windows. Looks like there is nothing much worth keeping from the GtkMozEmbed API, but we’ve gained valuable insight from the ways in which developers have struggled to use it.


  • Accessibility: We have several accessibility features, but no formal accessibility using ATK. Contributions here are welcome, otherwise I’ll look into adding support in a few weeks.
  • Patches already available but not yet integrated:
    • #15610: International/complex text rendering support using Pango. The Imendio guys are working to complete and integrate my initial work on this feature.
    • #14120: Input method support using GTK+ input methods
    • Inline search API (Update: Adam Roben from Apple has pointed out that this can be worked around by calling into window.search using the JS C API for now)
    • #15576: GtkPrint support using Cairo

GtkHTML is used primarily in Evolution. Again, there is nothing much worth keeping from the GtkHTML API as far as I can tell. WebKit now has excellent editable content support and exposes necessary public API for basic editing. Complex modifications will soon be possible using the GObject DOM, but until then, the DOM can be easily manipulated using the JavaScript C API (more on which soon).


  • emacs keybinding support using GtkBindingSet (see also #15911). Perhaps an emacs user can provide this?

Is your application hitting limitations in these text viewing/editing components? Any that I’ve missed? Do speak up now so we can cater for your use-case in WebKit!