[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