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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
