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
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
- #15610: International/complex text rendering support using Pango. The Imendio guys are working to complete and integrate my initial work on this feature.
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!
I haven’t looked at this for a while so could be wrong but…
Why isn’t there a webbrowser widget in glade ?
Whether it’s gtkwebkit or gtkmozembed… whichever (even both!) it makes so much sense and yet isn’t there 🙁
Wonderful job, looking forward to using GTK/WebKit-based browsers in the future.
Stu: with introspection I believe glade should automatically pick your widgets, without knowing about them a priori. I don’t think it works yet though.
Alp,
Coming to this party late, but the thing I *really* need from the GtkHTML API is the ability to intercept loading of alternative URI schemes. I know there’s an open bug on this in Mozilla, but I didn’t see any way to do this as yet in the GTK+ port of WebKit. Basically, I need the functionality of the “linked-clicked” signal present in the HtmlDoc API for GtkHTML2.
Do you know if there’s any plan for this sort of thing in WebKit? If so, that’d be great. If it’s there, it’ll only be a short time before it’s available in the Ruby language binding (which is what I’m using at the moment). I found a reference to this functionality in the Android developer kit shouldOverrideUrlLoading, but I can’t seem to find anything in the WebKit/GTK+ stuff using (I haven’t gone through all the source, though….)
Thanks in advance for any info, and sorry if this is a bit of a daft question.
Cheers,
ast
Andrew,
This is a very good question. It was left late as we were still settling on the HTTP backend, which is now libsoup. At some point there was the possibility that such an HTTP backend might deal with the virtual URI schemes as well, but I think that’s not part of the plan now. I believe an alternative has been developed.
I’m pretty sure you can already do this by using the navigation-policy-decision-requested signal. Both devhelp and yelp use a similar strategy. You may want to check it out.