[webkit-qt] QML2 WebView behaviour

Tue Mar 27 13:41:43 PDT 2012

Hi,

I'd like to get https://bugs.webkit.org/show_bug.cgi?id=76416
addressed.

That was possible in C++ with QWebPage::setLinkDelegationPolicy() and 
catching the linkClicked(QUrl) signal.

In QML it is not possible.  This makes doing things like ebook readers 
using webview unnecessarily complicated.

In iOS the equivalent functionality is
http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html
Surely Qt should be able to do what iOS does?

For QML, as a workaround I tried to use a custom network manager, but 
results are too crude, for instance image links seem to be difficult to 
handle.   Even conceptually it leaves a bad taste in my mouth, when all 
content is local and the point is that network is not needed.

Just my 2 cents,

Harri

On 03/27/2012 09:47 PM, Alexis Menard wrote:
> 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
>
>