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

[Alexis Menard]

Hi,

On Wed, Oct 19, 2011 at 10:27 AM, 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
>

I don't like the extra level of indirection letting the view class
alone with almost no properties.

TouchWebView {

    page {

    }
}

You are quite limited in what you can do in page {} which is why I
don't like. I have to move all my local code/properties in the view
and prefix all by page.something. The grouped property page is only
sugar for signal handling and property assignment, you can't do
nothing else in there.

It's obviously just taste here. I do see the use case of anchoring but
I'm not sure we should reflect it in the desktop view API itself. In
the other hand I like the fact you want to unify some stuff :D.

No strong opinion here but just a reminder. For example for the
experimental thingie, I had troubles to get it working because this
page {} indirection. I still have to do the bug report for QML about
it but I'd say they would not allow to do this :

TouchWebView {

   page {
       private {
           webGl: true
       }
   }

}

And yes it seems logical I attach the private thingie on the page as
it is where the private API is.
-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil