[webkit-qt] QML2 WebView behaviour

[Kenneth Rohde Christiansen]

This pretty much sums up my feelings. :-)

Regarding scroll indicators; mac already have them, so does GNOME, and
the Windows 8 Metro will as well, so I don't really think this will be
any problem. We are just a bit in front of our time :-)

Kenneth

On Tue, Mar 27, 2012 at 8:05 PM,  <simon.hausmann at nokia.com> wrote:
> Hi,
>
> I'd like to raise the topic of the behaviour of the QML2 WebView element across different platforms and devices once more.
> Before we get into details however, I'd like to clarify one rather important assumption or boundary condition about this element:
>
>    The purpose of the QML2 WebView element is to enable the embedding of web content in applications. This purpose should be
> served on all platforms QML2 runs on, including (but not limited to) traditional desktop platforms and all sorts of mobile devices.
>
>    Writing a fully fledged web browser is beyond the scope of the element and its API. Doing so requires a much tighter integration
> that what the publically supported API can currently offer. We should right now not clutter the API with functionality needed only by a
> browser and apply the same to behavioural/visual aspects of the WebView element.
>
> Anyone interested in developing a browser on top of the same "technology" (QML2, WebKit2) may find the QML API a great starting
> point, but it will at this point always require the use of private API.
>
> So with application embedding use-cases in mind, I'd like to revisit the discussion about how the WebView element should behave
> across different platforms.
>
> I recall our intent of giving the WebView a rather automatic behaviour when it comes to the appearance.
>
>    (1) For example that on Windows it should look and behave like a traditional desktop web browsers, with scrollbars out of the box, layout
> according to the element's width and platform themed form elements / popups.
>
>    (2) At the same time when we were talking about fun mobile platforms like the N9, the intent was to let the WebView be like the browser's
> viewport: A fixed layout for web content, no traditional scrollbars, behaviour as if the element was a QML2 Flickable (also in terms of
> connecting it to scroll indicators).
>
> If you look at this from the point of view of writing a browser, it kind of makes sense. But I'm starting to seriously doubt that this is a good
> behaviour from an application embedding point of view, because it is unpredictable and inconsistent compared to other QML elements. Another
> example of this extensibility in the API: In the experimental section we've been playing with the ability to allow users of the API to provide QML components
> that will be instantiated for dialog functionality, like alerts or file uploads. It's not clear what these should be like on "desktop" platforms, neither how to
> implement them nor what the default should be (should there be one on windows but not on Linux?)
>
> So instead I'd like to propose that we give the QML2 WebView element one consistent behaviour and appearance across all platforms:
>
>    * No scrollbars
>    * UIProcess sided scrolling with the kinetic flickable behaviour.
>    * Public inheritance from flickable would give one clear interface for scroll indicators
>    * Semi-fixed layout (using properties that _can_ be bound to the element's with - Jocelyn, do you remember the details of our discussion?).
>    * Form elements according to current "mobile" theme (this has room for improvement if we manage to encapsulate the themeing like in Chromium)
>
> (In a nutshell: The currently implemented default!)
>
> I believe this would give us also consistent behaviour for things like QML components for dialogs, because if for example filePicker is not defined, it
> simply won't appear, there's no need for a "default" in WebKit.
>
> One aspect to consider here also in the light of the desktop platforms is Qt desktop components. If Qt components for the desktop gets new momentum
> in development, it could easily provide a WebView element itself that
>
>    1) Uses the QML2 WebView element as basis perhaps
>    2) Can certainly use private APIs to provide a traditional with-scrollbars-and-platform-theme element
>
> In the scope of Qt desktop components such an element would make perfect sense, I believe. If somebody wants to develop a web browser using
> QtWebKit and Qt 5 for desktop platforms (Qrome? ;-), then nothing stands in the way of contributing to the private API and developing perhaps a new
> QML element that could one day become publically supported API. But in the meantime the QML2 WebView component has one behaviour everywhere,
> a highly customizable building block for creating QML based applications that embed web content.
>
> What do you think?
>
>
> 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
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ﹆﹆﹆