[webkit-qt] WK2 QML api: View and Page classes

[Jocelyn Turcotte]

An update on the subject, we opted to go for putting the API in the View classes.
We chose this mainly because of a couple of QML limitations regarding grouped properties (i.e. the "page" property).

https://bugs.webkit.org/show_bug.cgi?id=71280 is the bug for the change.

thanks for the feedback,
Jocelyn


On Wed, 19 Oct 2011 15:27:15 +0200
ext Jocelyn Turcotte <jocelyn.turcotte at nokia.com> wrote:

> Hello list,
> 
> I'm trying to merge as much functionalities between the desktop and touch view, and the first step is to unify their API regarding page methods and signals. Right now, QDesktopWebView has all its API in the View class (there is no Page class) and QTouchWebView has all its API in the Page class (there are few methods in the View class).
> 
> We either have to:
> 1. Create a QDesktopWebPage and move most of the API there (have APIs in the Page class)
> 2. Move most of the API from QTouchWebPage to QTouchWebView (have APIs in the View class)
> 
> The reason we currently have a Page for touch but not for desktop is to support anchoring items to the page, like in this example Tor Arne quickly cooked: https://gist.github.com/1298139
> 
> === Here is an overview of the pro/cons of putting APIs in the Page class (1.):
> - Resembles what we have for our WebKit1 API.
> - Makes the separation cleaner by using the WebView as a container, and put page related logic under the page.
> - Reduces the chances of the Desktop/TouchView becoming a monster class where everything ends up.
> 
> === Pro/cons for putting APIs in the View class (2.):
> - Reduces ambiguity and number of ways to do things: most of QWebView API is forwarding calls to existing QWebPage or QWebFrame methods, e.g. QWebView::settings() and QWebPage::settings().
> - Makes using the API a bit simpler by putting all handlers/methods right under the View, Page and View will always have a 1:1 relation anyway.
> 
> The reason I ask is that the choice isn't obvious and might affect the flexibility/usability of the API in the future. Do you have a preference or see other arguments for one or the other?
> 
> best regards and stuff,
> Jocelyn
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt