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
signature.asc
Description: PGP signature
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
