[webkit-qt] decidePolicyForNavigationAction QML API

[Chang.Shu at nokia.com]

Another problem of the current API is that the policy enums have to be
duplicated in each of the concrete classes (DesktopView and TouchWebView)
from PolicyInterface. The root cause of it is because PolicyInterface is
hidden. Would this be addressed in the proposed change? Or it should be a
separate effort?

Thanks
Chang

On 10/13/11 12:56 PM, "ext simon.hausmann at nokia.com"
<simon.hausmann at nokia.com> wrote:

>Hi,
>
>The DesktopWebView QML element has an API that corresponds to the
>ChromeClient's decidePolicyForNavigationAction (and work is under way in
>bug #69572 to implement the same API for the touch webview). The API is
>currently structured like this:
>
>DesktopWebView {
>
>    function navigationPolicyForUrl(url, button, modifiers) {
>        // Make decision here
>    }
>
>}
>
>I'd like to change this API for four reasons:
>
>1) The double-mentioning of url in  *PolicyForUrl(url looks strange :)
>
>2) It is only possible for instances for the QML element to decide on the
>policy.
>
>3) The API is synchronous, while the underlying implementation in
>WebKit2/ChromeClient is asynchronous. So while the engine can do it, our
>API forces the application to make a synchronous decision.
>
>4) Only the magical presence of the function with the right name makes it
>possible for applications to decide on the policy. Qt Creator cannot
>provide any assistance in terms of completion.
>
>
>I'd like to propose the following alternative API instead, that addresses
>all four points:
>
>The WebView component gets a signal navigationRequested (naturally the
>name is just a proposal) that provides a "NavigationRequest" object (that
>internally wraps a WKFramePolicyListenerRef) and which provides
>corresponding methods/slots for use/download/ignore. This changes the
>usage to the following pattern:
>
>DesktopWebView {
>    id: view
>
>}
>
>Connections {
>    target: view
>    onNavigationRequested: {
>         // ...
>         request.accept();
>    }
>}
>
>Note how the decision can be made anywhere in QML, it is up to the
>application whether to respond synchronously or asynchronously and Qt
>Creator offers signal completion for the signal when typing.
>
>
>What do you think?
>
>Simon
>_______________________________________________
>webkit-qt mailing list
>webkit-qt at lists.webkit.org
>http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt