[webkit-qt] QML2 WebView behaviour

simon.hausmann at nokia.com simon.hausmann at nokia.com
Tue Mar 27 11:05:12 PDT 2012


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



More information about the webkit-qt mailing list