Hi, Laszlo, Tor Arne and I had a brief discussion yesterday about four topics of the WK2 QML API. I'll try to summarize our conclusions so that we can continue iterating here on the mailing list for example (i.e. get more input/feedback).
1) Private APIs Tor Arne is working on that one in bug https://bugs.webkit.org/show_bug.cgi?id=67707#c11 . In a nutshell using QML extension objects we can have the following syntax: Rectangle { width: 800 height: 600 WebView { anchors.fill: parent experimental { webGLEnabled: false onSomeRandomThingChanged: console.log("yeah") } } } and experimental is "versioned" independently from WebView. 2) Resource handling There are two application use-cases that we'd like to cover at some point in the public API, which boil down to the task of feeding data (html, images, etc.) into WebKit(2). For example Qt Assistant wants to show its own html and images from the (in-process) help database, or an email application wants to show html email which can refer to images that are part of the multi-part messages using the cid: scheme. We concluded that we should be able to dedicate these use-cases to URI schemes, i.e. qhelp:// or cid:. With that in mind we could have a (declarative) scheme handler registration: WebView { experimental { schemeDelegates: [ "about": { // handler function takes "request" and "response" parameter if (request.url = "about:browser") response.send("...."); ] } } As the scheme delegates are a list property, they can also be extended dynamically. QNAM or the ResourceHandle implementation further up on the Web Process side would delegate such registered schemes using simple CoreIPC messages to the UI process. This clearly needs refining when actually implementing it, but the concept should cover the use-cases. The exact definition and behaviour of the scheme handler function should probably be inspired by existing JS APIs that implement the task of "servlets" used to serve HTTP requests. 3) Dialogs (Alert, Confirmation) 4) Context Menu We kind of put those into the same category and realized that there are two things we want: 1) A sensible out-of-the-box behaviour/implementation 2) The ability (in the future) to customize. We figured one possible "QML" way of doing the customization would be by using a pattern similar to the delegate components in the item views: WebView { experimental { uiDelegate { alertDialog: Component{ Dialog { .... } } contextMenuItem: MenuItem { } // Properties set by WK2 implementation contextMenu: Component { property list<Item> contextMenuItems; // Property set by WK2 implementation ContextMenu { MenuLayout { children: contextMenuItems; } } } } } } One potentially interesting aspect of this approach is that the default implementations of the ui delegate could use different versions of Qt Components and could be encapsulated in their own qml files that we can ship. Simon _______________________________________________ webkit-qt mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
