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: [email protected] 
[mailto:[email protected]] On Behalf Of ext Kenneth Rohde 
Christiansen
Sent: Thursday, October 06, 2011 6:48 AM
To: Hausmann Simon (Nokia-MP-Qt/Oslo)
Cc: [email protected]
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 <[email protected]> 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
> [email protected]
> 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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt

Reply via email to