If you happen to be going, drop by on my WebKit Mobile presentation, 14:00 Room 01 this Monday. We have a small surprise waiting for Maemo developers.

View slides (PDF format)

Demo sources

• Hosting a Dashboard widget
  • Simple example without JS integration

(Will update this post with more demo code over the next few days.)

Citations

• Slide 20:  All the cool kids are doing it (February 3rd, 2008) — donscorgie.livejournal.com
  
• Slide 30: WebKit and XULRunner (Mozilla) side by side on the XO (August 2nd, 2007) — j5live.com
• Slide 32: WebKit testing methodology for reproducible mobile benchmark performance results
• WebKit/GTK+ build instructions

“WebKit/GTK+ is a brand new port of the WebKit content engine providing standards compliance, high performance and seamless integration with the GTK+ stack. I’ll be demonstrating some of the latest features and taking a look at the ways developers can adopt the WebView API and apply HTML5, CSS, SVG, canvas and AJAX to create location-aware hybrid Web/GTK+ rich internet applications.”

Update: You can now get the slides from the talk.

What?

The talk will be short and light (only a 1/2 hour session) but I’ll be around all weekend so feel free to touch base if you have more questions or ideas. This session will target:

• GTK+ developers
• Web designers
• Anyone looking to deploy online and offline Web applications
  • on the desktop
  • on mobile devices

When?

11:15 - 12:15, Sunday, February 24, 2008

Where?

FOSDEM GNOME/Cross-desktop Developer Room, H.1301

Brent Fulgham has been merging Cairo graphics backend features from the Adobe Apollo/AIR branch of WebKit (#16558, #16577, #15382). The Adobe developers have been cooperative and their code is well-written — hopefully they’ll start merging their own work soon. This puts the graphics backend a couple of weeks ahead of schedule (the original target was GNOME 2.24):

Acid2

Luca Bruno has provided the last (#16365) in a series of fixes to get the Acid2 smiley face rendering correctly. This should help dispel rumours that the WebKit/GTK+ team is dropping acid.

Image decoder enhancements

Google engineers have contributed a handful of improvements (#15974, #16169) to WebKit’s image decoders, which will be shared between the GTK+ and Android ports.

Mobile features designed for Android can also now be easily enabled in the GTK+ port (eg. LOW_BANDWIDTH_DISPLAY support, r28960). It’s great to see cooperation on features like this.

Trunk open for Maemo/Hildon

The Maemo/Hildon mobile platform (used in Nokia internet tablets and Ubuntu Mobile) is now an official component of the GTK+ port. This means that these libraries can be used directly in WebKit instead of being maintained out of tree.

The JavaScript engine has seen recent optimizations which bring it further ahead of the stock browser shipped in OS2008 for the N800/N810 devices. Check out any of the freely available JS/AJAX benchmarks if you’re interested in performance.

GtkPrint

Initial printing support (#15576) has landed. Cairo’s paginated surface API lacks some features we need to implement this fully. I’ve posted a proposal for new API that will be useful in matching the print functionality of the Mac and Win ports.

I don’t really care much for browser wars, but since this post touches on so many aspects of the browser that I’m working on, like Cairo graphics, native widget styling, transparency and complex script support, I thought I’d give a reply.

• WebKit/GTK+ doesn’t really attempt to compete with Mozilla or Firefox in the browser space. It instead targets application developers who want a full-featured browser engine with a fun, powerful GTK+-style API. gtkhtml and gtkmozembed have proved to be inadequate, too heavy or un-portable.
• In the mobile and embedded space, WebKit/GTK+ is mostly competitive with Opera and NetFront rather than Gecko. I can think of only once that a vendor has come along and asked how it compares to Gecko on mobile devices.
• We’re working with the developers of general purpose browsers like Epiphany and Midori, as well as domain-specific Web applications like the GNOME documentation browser Devhelp, and mobile platforms like the Maemo browser EAL and OpenMoko’s browser and feed reader to make sure WebKit can provide all the features they need. It turns out they don’t need a UI toolkit like XUL since GTK+ provides the functionality they need, so we aren’t attempting to bundle a toolkit with our browser engine.
• WebKit/GTK+ is not tied to Linux. It’s portable to OS X and Windows. Behaviour on those platforms is intended to be similar to that on Linux, and the API on all platforms is identical.
• It can render that “Hello” button correctly. It also supports a bunch of fancy features from HTML5 and CSS3 that Gecko does not and loads pages faster before optimisation work has even started, but I don’t think we need to go into a feature-for-feature debate here.

An application hosting OS X Dashboard widgets (widgets can store data locally using HTML5 client-side database storage):

An implementation of Freedesktop notifications using Growl WebKit styles (incidentally, work is ongoing to provide integration with various Freedesktop specifications where appropriate):

An example of native widget styling:

The talk covers some of the history of both the WebKit browser engine and the WebKit/Gtk+ port, looks at the ethos of the developer community and explores current and planned features, such as SVG, Canvas and audio/video. It goes into detail about work involving the Nokia N800 internet tablet and Maemo as well as a brief look at integration work being done by the OpenMoko project, the state of play with OLPC and, of course, GNOME’s Epiphany web browser and Devhelp documentation browser.

Download WebKit/Gtk+ talk slides

WebKit/Gtk+ will soon be joining Opera and Mozilla as a well-supported alternative browser for the Maemo platform. I believe we are the first to provide SVG support:

It’s exciting to hear the Red Hat guys have been experimenting with WebKit/Gtk+ on the OLPC platform — J5 is a competent engineer and his comments have helped to give us direction for further development.

Given also the recent activity on Epiphany/WebKit, these are good signs that we’re working towards a usable browser engine both for mobile devices and the desktop, but there are still features to be implemented and bugs to fix, and I encourage those interested to get stuck in to the WebKit bug tracker, whether filing bugs or contributing patches.

Great credit goes also to Holger Freyther of the OpenMoko project, who is co-maintaining WebKit/Gtk+ upstream in Apple’s SVN repository along with me (we completed paperwork with Apple to become SVN committers about a month ago) and has been dealing with some particularly involved parts of the port involving scrolling, frames and native widgetry.

I started working on the port half a year ago after giving up on gtkmozembed in a fit of frustration and was immediately impressed by the competence of the WebKit team and the abstractions they’ve made on top of the browser core to make porting a breeze — WebKit boasts successful and actively maintained “ports” to Qt, Wx, Gtk+, Mac OS X and Windows. These guys know what they’re doing and have rapidly learnt how to lead a successful Open Source project. Porters often work together and each of the ports share various modules and backends — GNOME developers are known to work with qmake, KDE hackers have picked up amounts of Gtk+ knowhow and Apple engineers often provide build fixes and small feature enhancements for the contributed modules.

The engine is incredibly versatile, and, as the name suggests, one of its strong points is seamless integration into existing desktop applications. We are concentrating on the mobile GNOME platform right now, and even without any profiling, the prototype browser is competitive with Opera, particularly for complex interactive sites using AJAX and modern CSS features. Moreover, we see a future for WebKit as a component of new applications like Banter that are blurring the boundaries between rich Web content and the GNOME desktop.

One of our upcoming contributions will add support for WebKit’s KSVG2-based SVG functionality using Cairo:

This is distinct from existing Cairo SVG libraries like librsvg in that JavaScript has full access to the DOM here, much like the current Gecko development trunk.