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

[Yael.Aharon at nokia.com]

QTouchWebPage is nothing like QWebPage or QWKPage.
To me, it is very confusing that it has "page" in its name.
I would rename it to something that reflects better what it really is.
Yael


On 10/6/11 11:04 AM, "Simon Hausmann" <simon.hausmann at nokia.com> wrote:

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