[webkit-gtk] WebKit2 GTK+ API

Carlos Garcia Campos cgarcia at igalia.com
Tue Sep 20 11:57:13 PDT 2011


El Tue, 20 Sep 2011 15:15:30 -0300
Gustavo Noronha Silva <gns at gnome.org> escribió:
> On Thu, 2011-09-15 at 11:50 +0200, Carlos Garcia Campos wrote:
> >  - 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.
> 
> What do you think of splitting WebKitWebView in more objects with
> fewer responsibilities each?

I like the idea. Martin and I have talked about the possibility of
adding an interface for the load progress stuff, and a default
implementation of that interface that would emit the signals. Something
like:

WebKitWebLoaderClient: interface with a method for every callback
WebKitWebLoaderClientDefault: default implementation used by webview
that emits signals like the current web view does.

WebKitWebView would have something like:

WebKitWebLoaderClient *webkit_web_view_get_loader_client(WebKitWebView);
void webkit_web_view_set_loader_client(WebKitWebView, WebKitWebLoaderClient);

So, you could use the default implementation:

g_signal_connect(webkit_get_view_get_loader_client(), "foo", ...)

Or implement your own loader client and call
webkit_web_view_set_loader_client().

> For the clutter port we split most of
> WebView into a WebPage object that has no dependency and knowledge of
> the widget, and that brings some interesting possibilities to the
> table, like enabling us to provide different widget types that not
> necessarily inherit from the same parent, and provide a 'headless'
> mode.

I like the idea of having WebKitWebPage too, WebKitWebView currently
wraps a WKPage indeed.

> I very much welcome this initiative, by the way, thanks for pushing
> it! I'll try harder to keep up, discuss and contribute, I think it's
> a great opportunity to flesh out some great API.

Great, thanks!

> Cheers,

Regards, 
-- 
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/20110920/588023f8/attachment.bin>


More information about the webkit-gtk mailing list