[webkit-qt] QML2 WebView behaviour

Alexis Menard alexis.menard at openbossa.org
Tue Mar 27 12:44:35 PDT 2012


On Tue, Mar 27, 2012 at 3:05 PM,  <simon.hausmann at nokia.com> wrote:
> Hi,
>

Hi Simon,

> 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

I really don't like that. I wonder how I will scroll on desktop with
my mouse? On Mac when you plug a regular mouse the scrollbars keep
being always visible -> good. When you use the magic trackpad and
unplug the mouse they hides automatically.

>    * UIProcess sided scrolling with the kinetic flickable behaviour.

On desktop with a mouse (not a magic track pad) it doesn't make any
sense to me if it it like today in the mobile mode (i.e. I left click
and long press it and it kinetic scroll). It's awkward at best, it's
nice to play with but not useful. On Mac when you have a regular mouse
it doesn't do any flickable effect while left clicking unless you
start using the trackpad with two fingers. We should do the same as
everyone doesn't seem to be bothered with the way it works.

Of course the wheel needs to work.

>    * 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)

The latter needs to be improved on desktop. I already talked to Pierre
about that.

All my use cases are based on let say a RSS reader on desktop.

>
> (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



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil


More information about the webkit-qt mailing list