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

[Simon Hausmann]

On Thursday, October 06, 2011 02:43:39 PM Aharon Yael (Nokia-MP/Boston) wrote:
> Hi,
> While redesigning the API, would it make sense to rename QTouchWebPage to something that reflects its new role?
> QTouchWebPage is by no means a replacement of QWKPage and the name is very confusing.

It depends, in QML it's only visible as "page" group property. QTouchWebPage is not exposed as a name or C++ class.

What exactly would you like to change?


Simon

> -----Original Message-----
> From: webkit-qt-bounces at lists.webkit.org [mailto:webkit-qt-bounces at lists.webkit.org] On Behalf Of ext Kenneth Rohde Christiansen
> Sent: Thursday, October 06, 2011 6:48 AM
> To: Hausmann Simon (Nokia-MP-Qt/Oslo)
> Cc: webkit-qt at lists.webkit.org
> Subject: Re: [webkit-qt] WK2 QML api discussions, round 1
> 
> Just wanted to say that this sounds all good to me. We will need some signals as well to tell when an item got activated etc.
> 
> Kenneth
> 
> On Thu, Oct 6, 2011 at 9:41 AM, Simon Hausmann <simon.hausmann at nokia.com> wrote:
> > 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
> > webkit-qt at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
> >
> 
> 
> 
> --
> Kenneth Rohde Christiansen
> Senior Engineer
> Application and Service Frameworks, Nokia Danmark A/S Phone  +45 4093 0598 / E-mail kenneth.christiansen at gmail.com
> 
> http://codeposts.blogspot.com ﹆﹆﹆
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>