On Tue, Sep 20, 2011 at 8:10 PM, Gustavo Noronha Silva <[email protected]> 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. _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
