Alp Toker

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

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.

Challenges:

• 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

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.

Challenges:

• 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.
  • #16135: We’re adding caret-based browsing support straight into WebCore.
• 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

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

Challenges:

• 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!

In my talk at LCE 2007, I touched on the issue of proprietary branches and their effect on developer morale.

On the WebKit/GTK+ team, we’ve had to deal with this issue a few times.

• A year ago, Adobe promised great new graphics features from their AIR fork of WebKit that never materialised. We chose to redouble efforts to improve the open Cairo graphics backend instead of sitting about waiting for their contributions, a decision that has paid off.
• More recently, a company has been working on a largely proprietary fork of the browser called OWB. It is remarkable that, looking at some of their recent code drops (which cannot be easily merged back to trunk due to refactoring), they still have bugs and performance issues that we fixed in WebKit trunk several months ago. It’s sometimes unpleasant to implement features that others are working on behind closed doors, but we do it in an open forum with peer review. What’s more, we do it better.

Fast forward, November 2007

Today, Google announced that it’s developing a WebKit-based browser as part of its Linux-based Android mobile platform.

In the hours since this news came about, contributors have already started to ask whether their work is about to be obsoleted or replaced by a Google code drop. It’s inevitable that there will be some overlap.

I’d like to make it clear that we’ve already discussed this scenario, and it’s life as usual for the GTK+ port. If there are contributions to components of the GTK+ port, they will be reviewed through the same processes as any other contribution.

Furthermore, it’s likely that WebKit/GTK+ already has superior graphics capabilities to any forked browser since we’ve been tracking the very latest features including recent SVG updates, CSS transformation and CSS animation support. Another WIP feature of particular interest to mobile devices is the upcoming full page scaling support.

With current efforts to bridge Web applications and the underlying platform and research into features like bridging JavaScriptCore to D-Bus and other frameworks, it’s likely that we are also ahead of the game in the Web-as-a-platform department.

All that said, I look forward to working together with the developers of the Android platform towards a more open and flexible mobile Web!