[webkit-dev] Porting Gtk+WebCore

Maciej Stachowiak mjs at apple.com
Fri Jun 10 00:02:48 PDT 2005

On Jun 8, 2005, at 9:55 PM, Kimmo Kinnunen wrote:

> Hi,
> I understand there might be interest in hosting Gtk+WebCore under  
> opendarwin, possibly merging some changes back to the real WebKit.  
> I think this is quite good idea.

Yes, we'd love to see this happen! We're very interested in making  
our tree multiplatform and multitoolkit, and the Gtk+ port is very  
high on the list since it already exists. :-)

> Does anybody have any ideas how should this proceed? There's not  
> much change in the core that could benefit WebKit on OS X. From  
> other platforms' point of view, there's probably the ARM fixes,  
> some linux compilation fixes and maybe Gtk+ KWQ.

We haven't yet worked out the details. But I think the ARM and Linux  
compilation fixes are a no-brainer to go in (as long as the code also  
still compiles on OS X) and if you sent patches along those lines,  
we'd gladly take them.

> Status of the Gtk+WebCore:
>  - JavaScriptCore 413
>  - WebCore 145.1
>  - Running on Linux (x86 and ARM), FreeBSD, using Gtk+
>  - Proof of concept support for Cairo
>  - Runs also on Win32 with Gtk+ (VC6 I believe), no GDI image renderer
>    though
>  - Lots of crashes, mostly from our Kit-side.
> The problem of course with the Gtk+WebCore project was that there's  
> no platform to integrate in, so every service, like networking and  
> graphics, come from assorted libraries.

Yep, that's unsurprising. It's fine to depend on external libraries  
for these, for the Gtk port.

> Still, porting WebKit to other platforms has questions that puzzle me:
> The build system seems to completely rely on OS X. Is there any  
> plans to use makefiles, autotools or something? From OS X developer  
> point of view, I'd speculate that the whole hassle with autotools  
> is pretty inferior to what you got there.. If there was a  
> multiplatform WebKit, what kind of infrastructure would there be?

This is a question that some of us on the Safari/WebKit team have  
thought about, but we're not sure which way to go yet. As I see it,  
there's two basic options:

A) Use autotools on every possible platform, even Mac OS X. We used  
to do this way long ago towards the start of the project, and over  
time we converted to Xcode because of all the nice things we get from  
it. So in some ways this would be more of a pain for the existing  
WebKit developers at Apple.

B) Use Xcode projects on OS X, and autotools for ports to more  
traditional unix systems (Linux, FreeBSD, etc). The major downside to  
this is that to make any kind of build change (even just adding a new  
file), you would have to do it twice. And not only that you would  
really need a Mac even if that is not your primary dev platform,  
since the Xcode project file format is not really human-editable.

We're really not sure yet which of these is better. I think it might  
be best to start with B, and consider converting to A someday if  
there are enough active developers on non-Mac platforms.

> KWQ side of WebKit is also heavliy OSX dependent. Any ideas how to  
> make this different? Especially refactoring the bridge and  
> generalizing the KWQ widgets to support Carbon, Gtk+, Windows  
> widgets needs a bit of thought.

There's really several different things in the KWQ directory:

1) Fairly platform-agnostic replacements for things like data  
structures and QString (QDict is one exception here, but we'll be  
changing that to not rely on CFDictionary any more). These could just  
be used for any platform that uses KWQ instead of the real Qt.

2) Completely platform/toolkit specific implementations of the Qt  
widgets. We'd need separate implementations of these per port - I'm  
not sure how much of the code if any is shareable across ports.

3) Bridging logic, for binding to an API wrapper layer. This is  
mostly KWQKHTMLPart and WebCoreBridge. Unfortunately these have

4) Bridging to system APIs that are implemented in WebKit, stuff like  
WebTextRenderer.m. This might not be needed at all for other ports.  
I'm not really sure.

> I think the main issues are defining how the WebKit portability  
> project relates to the Apple's WebKit. Anyway, I can happily help  
> porting the Gtk+WebCore. It'd be great even if the project was just  
> hosted at opendarwin, because then it might attract more people  
> actually working on it.

That would be awesome. We'd definitely be happy to host it here, and  
we would do our best to encourage more contributors.


More information about the webkit-dev mailing list