[webkit-gtk] WebKit2 GTK+ API

[Carlos Garcia Campos]

El Thu, 15 Sep 2011 14:39:15 +0200
Alejandro Garcia Castro <alex at igalia.com> escribió:
> On Thu, Sep 15, 2011 at 11:50:22AM +0200, Carlos Garcia Campos wrote:
> >
> > [...]
> > 
> > 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.
> 
> I've talked to Carlos and just wanted to do some clarifications about
> what this would mean. Developers will have to use an API where they
> add the callbacks for the function instead of connecting to signals,
> for instance, load uri was:
> 
>    webkit_web_view_load_uri         (WebKitWebView *webView,
>                                      const gchar   *uri);
> 
> And now would be:
> 
>    webkit_web_view_load_uri         (WebKitWebView      *web_view,
>                                      const gchar        *uri,
>                                      GCancellable       *cancellable,
>                                      WebKitLoadProgressCallback
> progress_callback, gpointer progress_callback_data,
>                                      GAsyncReadyCallback callback,
>                                      gpointer            user_data);
> 
> libsoup is also using currently this same kind of solution [1].

This is similar to g_file_copy_async(). In this case the
ProgressCallback provides the load status and progress as a double
between 0.0 an 1.0. I've also removed the failed state, when the
operation finishes (even if it's been cancelled), the GAsyncReady
callback is called, and if the load failed the finish() method returns
FALSE and GError contains the details. 

> I
> can think that developers would not ask anymore how to get the load
> progress, but the second API is uglier when you see it side by
> side. It is also true that the first one will also have code defining
> the signals that is not here. 

I'm not sure it's uglier, I guess it's a matter of taste, maybe I'm too
used to gio API. I admit is a bit uglier when not using the callbacks:

webkit_web_view_load_uri (view, uri, NULL, NULL, NULL, NULL, NULL);

> It feels more natural to define all the data for the operation instead
> of connectin signals that are going to be there even though the
> operation is over. But this change goes against the first point
> so we have to be sure it makes sense. 
> 
> Just tried to add some more information, personally I'm still not sure
> which option we should choose or if we have to use the same for all
> this notifications, so please, dicuss!! 

Note that I'm not proposing using this for everything, just for async
operations started by the user. There are a lot of other cases where
using signal is more appropriate. 

> I'm adding Alexl and Company to the CC because they have experience
> with this async API.
> 
> br
> 
> [1]
> http://developer.gnome.org/gio/stable/GAsyncResult.html#GAsyncResult.description
> _______________________________________________ webkit-gtk mailing
> list webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
> 

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/20110915/f2cebf2f/attachment.bin>