El Thu, 15 Sep 2011 12:51:00 -0400 (EDT) Alexander Larsson <[email protected]> escribió: > > > ----- Original Message ----- > > El Thu, 15 Sep 2011 08:56:25 -0400 (EDT) > > Alexander Larsson <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
