[Webkit-unassigned] [Bug 68085] [GTK] Loader client implementation for WebKit2 GTK+ API

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Sep 21 23:37:40 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=68085





--- Comment #8 from Carlos Garcia Campos <cgarcia at igalia.com>  2011-09-21 23:37:40 PST ---
(In reply to comment #7)
> (From update of attachment 108136 [details])
> I like this approach a lot. We don't have to expose an interface at first, if we are unsure about it. 

In that case I don't see the advantage of using this instead of adding the signals to WebKitWebView. If I had to choose I would probably leave the interfac and not the default impl.

> One suggestion I have for the patch is to make the loader client responsible for creating the WK2 page client. The callback methods can call the interface methods directly -- they will receive it as their private data. Ths will reduce the amount of null checks and the code in WebKitWebView.cpp.

The view will need to do things in those callbacks too, for example update the uri, load error pages, update the title, etc. even if there isn't a loader client. That's why I create the loader client on demand. 

I'm also not sure whether we should expose all the C API callbacks in the interface, some of them doesn't seem to have anything to do with loading like processDidCrash or didChangeBackForwardList. So, for now I would only add the callbacks to replace the old load-status.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list