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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 22 08:36:46 PDT 2011


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





--- Comment #9 from Martin Robinson <mrobinson at webkit.org>  2011-09-22 08:36:46 PST ---
(In reply to comment #8)

> 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 think it makes sense to make private methods of the WebView available to the loader rather than making the entire entire loader interface available to the WebView. There will just be fewer methods and less boilerplate.

We could even make some of these tasks the responsibility of the loader. There's no reason the WebView should be the one keeping track of the URL. I can just ask the loader for it. 

> 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.

Let's keep them associated with the loader client unless they move to some other client in the future. It's confusing having the logic of the loader client handled by different classes, IMO.

-- 
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