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
