On Thu, Sep 15, 2011 at 3:23 PM, Carlos Garcia Campos <[email protected]> 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.
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. 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. 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...) Benjamin _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
