[webkit-gtk] WebKit2 GTK+ API

Carlos Garcia Campos cgarcia at igalia.com
Thu Sep 15 02:50:22 PDT 2011


It seems there's some confusion related to the WebKit2 GTK+ API, so
I'll try to clarify the current situation.

WebKit2 has a port-agnostic C API that ports can use to build their own
APIs on top. Our first idea was to implement the current WebKitGTK API
in WebKit2 using the C API and provide also the C API so that users
could choose which one to use. Then, we implemented the MiniBrowser
using only the C API and compiled GtkLauncher against the WebKit2GTK
API as GtkLauncher2. The main advantage was that applications using
current WebKitGTK wouldn't need to be ported to use WebKit2, they just
needed to build against the webkit2 lib. 

In the WebKit contributors meeting, apple guys said that they were
going to remove the C API, probably replacing it with a C++ one. There
are also some things that are bit different in WebKit2, that would make
implementing the WebKit1 API more difficult or even impossible, see
this comment for example:

https://bugs.webkit.org/show_bug.cgi?id=68055#c6

So, we thought that maybe it would be better to take advantage that
WebKit2 is a new library, and design a new API, as compatible as
possible with the old one, but removing all deprecated stuff,
modernizing it and making it as gnome-y as possible too. We would still
build this new API on top of the C one (without exposing the C API in
the GTK+ one, so that we can switch to the C++ one without modifying
the API). And the C API will still be available, since it's public, but
we won't encourage its usage, because it might be removed. So, the idea
is to remove the webkit2 support from GtkLauncher and port MiniBrowser
to the new GTK+ API. 

Since it's a big change, I would like to share some general ideas I
have about the new API so that we can discuss them. 

 - Try to keep webkit1 API when possible to make porting apps easier.
 - Use async API following the glib/gio pattern for operations started
   by the user like loading a page, finding text, etc. that has an end.
 - Use signals for actions not started by the user that can happen at
   any time.
 - Don't use signals for notifications on preperties, use notify
   instead. (These signals are already deprecated in webkit1 indeed)
 - The API should be non-blocking so try to not add sync versions of
   the methods unless it's really necessary.
 - And of course try be as gnome-y as possible. WebKitGTK+ should be
   used like other gnome libs.

Following these ideas I've started to write some patches this week:

[GTK] Add WebKitWebContext to GTK API
https://bugs.webkit.org/show_bug.cgi?id=67931

[GTK] Use WebKitWebContext in WebKitWebView
https://bugs.webkit.org/show_bug.cgi?id=67990

[GTK] Loader client implementation for WebKit2 GTK+ API
https://bugs.webkit.org/show_bug.cgi?id=68085

Comments?

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20110915/dd7e7955/attachment.bin>


More information about the webkit-gtk mailing list