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" <[email protected]> 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: [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
