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

[Yael.Aharon at nokia.com]

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.
Yael

-----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