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

Fri Sep 23 01:37:04 PDT 2011

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

Alejandro G. Castro <alex at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex at igalia.com

--- Comment #10 from Alejandro G. Castro <alex at igalia.com>  2011-09-23 01:37:04 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > (From update of attachment 108136 [details] [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.
>

I also have some doubts about the approach, adding two options is usually a way to confuse developers, because they have to decide if we do not say in which cases you should use one or the other. If we can explain that then we are ok with 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.

I would say that if we think this should be located in other API callbacks maybe we should propose a change in the C API, and get information about why they added it here, because I agree with martin that it is confusing just to fix it for ourselves adding the logic in other class.

Hope it helps.

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