[webkit-qt] QML2 WebView behaviour

[Alexis Menard]

On Tue, Mar 27, 2012 at 4:44 PM, Alexis Menard
<alexis.menard at openbossa.org> wrote:
> 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?

And selection need to work on desktop :)

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



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