[webkit-gtk] WebKit2 GTK+ API

[Carlos Garcia Campos]

El Thu, 15 Sep 2011 16:00:25 +0200
Benjamin Otte <otte at gnome.org> escribió:
> On Thu, Sep 15, 2011 at 3:23 PM, Carlos Garcia Campos
> <cgarcia at igalia.com> wrote:
> > 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.
> >
> What confuses me a bit about this operation (in particular when
> compared with g_file_copy ()) is that this operation operates on the
> webview, while copying is an operation with the file. So it is
> perfectly valid to do 5 g_file_copy() operations on the same file at
> the same time, while it is never valid to have more than 1 load
> happening per webview.

That's true, I used g_file_copy_async() example because it uses a
progress callback. 

> So from my perspective, the current API is perfectly fine. You have
> the WebView object, which exports a bunch of state to inspect and the
> possibility to modify it using certain APIs. 

No, you are not supposed to modify the status. I'm not saying using
signals is bad, I'm just proposing an alternative api based on glib/gio
async pattern. It would reduce the amount of signal and properties of
WebKitWebView, and I think it would make easier to handle the status.
In this moment there are two properties and one signal that you have to
monitor: progress and load-status properties with two conditions for
finishing the load operation, load-status changes and current value is
FINISHED or FAILED and load-error signal is emitted. 
With the async api you are sure that GAsyncReadyCb will be called when
the operation finishes, the status is FINISHED and in load failed, you
have a GError with the details. If we don't use the glib pattern for
async operations we should at least rethink the loading process. 

> It is in no way as bad as
> File or Socket IO where you don't have any state that you can inspect
> or even get notified of changes for. In fact, you have to open a
> monitor on the parent directory to figure out if a file changes its
> name, a GFile doesn't even represent a file, but rather a path on your
> filesystem, and therefor might change which file it points to without
> you ever noticing. From my point of view, this is bad design, don't
> try to copy it.

progress, load-status and load-error only make sense during loading, I
think it would make sense a property is-loading to query and monitor
whether the view is currently loading a page or not.

> This whole notion of async API is really ugly, I'd try very hard to
> avoid it at all costs. In fact, it's so bad that people do sync IO
> everywhere and pray nobody notices. (Try looking at the GTK icon theme
> code or the CSS theme loading or basically anything else inside GTK.
> Or try looking at lots of DBUS-using code that calls functions with
> return values. In particular AT-SPI...)

That's why I say in my first email that we shouldn't provide sync
versions of the methods. 

> Benjamin
> 

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/1f21ac50/attachment.bin>