GTK+ Matters
A friend pointed out a slightly confused post by a Mozilla developer regarding WebKit/GTK+.
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 point of the button was not the button itself, but the translucent, relatively positioned span that overlays it. That’s the kind of thing I don’t know how to render with real GTK+ buttons in the page.
I don’t know why I’m confused, but your work sounds cool.
Firefox only serves me as a web browser, XUL is a pig I hate and doesn’t match (no matter how much they try) my GTK theme. Epiphany is the way forward but I need extensions such as adblock and unplug and web developer. When epiphany+webkit does this, I won’t be keeping firefox anymore.
Webkit means so much to GNOME not just epiphany, finally something that works instead of gtkhtml, gtkmozembed etc… I imagine a day when rich web content can integrate into the desktop without glitches, seams and compatibility issues.
The only question I have is, WHEN WILL IT LAND!
Cool stuff – I’m looking forward to using gtk/webkit in the future… One slightly off-topic question; Is that a new theme, or are those GtkLabel-style frames around those lists? I noticed that the new Firefox uses GtkLabel-style frames everywhere too, which doesn’t really blend in with the rest of GTK :/ (even if it looks kinda nice)
Robert: When I saw the phrase “Apple with too much power over the free desktop” my immediate response was to deal with your post as flamebait, since (1) Apple has no power over and little relation to the free desktop today and (2) the port is not being done by Apple. I’ve updated my post with a screenshot of the “Hello” button, but I have to admit it’s no fun to respond to someone’s technical queries when they start by questioning the validity of your work.
Karl! We are on the case. Since we do not have a fancy evangelism department, the world doesn’t always get to hear about the latest features and integration work. Give it a few months, I’d say 😉
> Give it a few months
I’ll give you time till 2.22 😉
seriously, this is really cool 🙂 hope to get that soon on my desktop
I really really appreciate your work, go on, you’re defenitely on the right path! 🙂
Chris: You’re quite right. To some extent I think our hands are tied with what we can do given the apparent mismatch between the scrolling models of HTML controls and GTK+ widgets, but there is certainly some room for improvement here.
“Apple with too much power over the free desktop…”
— Mozilla developer, typing into Firefox on his Mac Book Pro
I really don’t want to add any Schadenfreude, but I’m thrilled about this: I think WebKit/Gtk+ does a Tour de Force because of what it is: A reusable easy-hackable featureful free-software library (aka “piece of code”), simply attracting attention for what it is and how well that model corresponds to how “pieces of code” on free systems are used and shared. People from all over simply realize they can use it too.
This is the monolithic mozilla vs lighter firefox comparison again: this time we need something truly library-like. The web is bigger than just the web browser and in some years Firefox will have adapted or been marginalized.
/me is happy to evangelize webkit/GTK+ on behalf of the project 🙂
just email me with a list of evangelizing topics and I’ll be happy to spread the love, word and plain brilliance 🙂
alp, I never meant to question the validity of your work. “Webkit is a good engine and getting it running in GNOME is a good thing”, like I said.
Can we forget that stuff and discuss how you’re doing the GTK styling? Are you instantiating one real GTK widget per HTML element and letting them paint themselves, or are you doing something more like what we do and calling gtk_paint_box etc?
Robert: There is still some widget instantiation in a few corner cases, but that isn’t unique to WebKit. We call gtk_paint_* for nearly all native themed widgets right now, and we are moving towards direct re-use of gtk2drawing.cpp from the Mozilla code-base.
The authors of gtk2drawing.cpp have put effort into keeping their code portable and independent of the rest of Mozilla, which is much appreciated.
gtk2drawing.cpp handles a lot of quirks that we don’t want to have to go through the process of re-discovering and I’m looking forward to sharing this work and contributing back to Mozilla as we make fixes or when the GTK+ style API is improved.
alp, that’s awesome. Glad to hear it!
A few more questions, if I may:
— how are you handling combobox dropdowns? Are you instantiating a real widget there?
— how are you handling widget rotation and other transformations? and printing widgets to PDF etc? If you haven’t discovered it already, you might find cairo-xlib-utils (which I wrote) useful:
http://mxr.mozilla.org/seamonkey/source/gfx/thebes/src/cairo-xlib-utils.h
http://mxr.mozilla.org/seamonkey/source/gfx/thebes/src/cairo-xlib-utils.c
Basically it lets you take code that expects an X drawable to draw it into, and makes it draw into an arbitrary cairo_t in an arbitrary state. It uses a temporary X pixmap if necessary. When the widget might draw partly transparent, it has to use two temporary pixmaps and do some calculation to recover the alpha values :-(. That’s obviously a horrible hack (although corralled inside a decent API IMHO) so…
— given that a lot of GTK themes actually use cairo to draw these days, have you talked to anyone about having GTK expose an API so we can just pass a cairo_t into a version of equivalent of gtk_paint_box etc?
There are other things we could talk about, like plugin handling, and the 16-bit-coordinate overflow problem in really tall overflow:auto elements. And if there’s anything you want to ask me, feel free. Comments in your blog might not be the best venue though.
Gecko and XUL are hogs and I’ve completely lost faith in Mozilla. WebKit has better standards support and is much faster. Unfortunately, as a GNOME user, I don’t have a lot of options for quality GTK+ web browsers that use WebKit. Midori is still too immature and not widely supported, Epiphany is still mainly Gecko focused; and trust me, I’ve looked at the source code for Epiphany. It has become way too complex, which is only going to slow down bug fixes and the adding of additional features. I’m working on my own browser at the moment since everything currently out there doesn’t meet my standards. I will definitely release it since I know that I am not the only one fed up with the current situation of browsers.