[webkit-gtk] WebKit2 GTK+ API

[Carlos Garcia Campos]

El Thu, 15 Sep 2011 12:51:00 -0400 (EDT)
Alexander Larsson <alexl at redhat.com> escribió:
> 
> 
> ----- Original Message -----
> > El Thu, 15 Sep 2011 08:56:25 -0400 (EDT)
> > Alexander Larsson <alexl at redhat.com> escribió:
> > >
> > >
> > > ----- Original Message -----
> > > > 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);
> > > >
> > >
> > > I'm not sure passing the progress callback like this is the best
> > > approach. It means e.g. that you have to reconnect the whole
> > > progress
> > > UI handling on each load, in say a webbrowser. Its a nice API if
> > > all your app does is load a single page, but not right if you
> > > want to always show the load status of the view in some other
> > > widget.
> > >
> > > One possible way to make the API "nicer" is to return a
> > > WebKitLoadOperation object and have progress signals on that.
> > 
> > what do you mean by return? if load_uri() returns the operation, it
> > might be too late to connect the signals and you would still have to
> > connect the signals for every load operation. Or do you mean
> > something like g_volume_mount() api that takes a mount operation as
> > parameter?
> 
> Yeah, i didn't think about it much, but obviously returning something
> will not work if the data loading is happening on some thread while
> we're returning from load_uri. In that case you have to pre-setup
> some object with where you already connected to the signals.
> 
> 

Maybe we could use the load operation object to unify all load methods
into a single one. We currently have 

webkit_web_view_load_uri()
webkit_web_view_load_string()
webkit_web_view_load_html_string()
webkit_web_view_load_request()

We could have something like:

WebKitLoadOperation *webkit_load_operation_new_for_uri()
WebKitLoadOperation *webkit_load_operation_new_for_html()
WebKitLoadOperation *webkit_load_operation_new_for_plain_text()
WebKitLoadOperation *webkit_load_operation_new_for_network_request()

webkit_web_view_load (WebKitWebView *view, 
                      WebKitLoadOperation *operation, 
                      GCancellable *cancellable, 
                      GAsyncReadyCallback callback, 
                      gpointer user_data);

But we would still have to connect the signals all the time for every
load operation, unless we could reuse the WebKitLoadOperation object,
I'm not sure, though.

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/bd18e88d/attachment-0001.bin>