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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
