[webkit-qt] WK2 QML api discussions, round 1

[Simon Hausmann]

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