[webkit-gtk] WebKit2 GTK+ API

[Benjamin Otte]

On Tue, Sep 20, 2011 at 8:10 PM, Gustavo Noronha Silva <gns at gnome.org> wrote:
> I think Company realizes that, but is arguing against gio-style async
> APIs, not about loading being async at all. I like the idea of clearly
> identifying that the API is asynchronous, but I'm not really sure using
> gio-style async APIs for page loading will be a good thing.
>
Yes.

My example would be the fact that gtk_widget_show() does in fact not
show a window, but queues the showing of the window on the X server.
But fixing this "deficiency" by introducing gtk_widget_show_async
(widget, cancellable, callback, data, error) is probably not the best
idea. So I'm arguing for an API - like GTK and WebKit have currently -
that is defined by 3 things:
1) functions you can call on it to start operations
2) properties you can query (synchronously) about the current state
3) signals that inform you about changes
and use async APIs only as a last resort for actions that neither fit
nicely into (1) nor (2). (An example for one such operation might be
copying the data for a dnd operation.) But I would try very hard to
avoid this async idiom. I am sure people are aware that calling
web_kit_web_view_do_foo() will return before foo is actually done.

Benjamin

PS: The same problem exists not just in WebKit or GTK, but also the
current accessibility implementation, everything else that operates
cross-process (over D-BUS, X, etc) is hit as well, so this is actually
quite a common problem and has been solved a lot of times.