[webkit-qt] QML2 WebView behaviour

Harri Pasanen grego at mpaja.com
Tue Mar 27 13:41:43 PDT 2012


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

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


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

More information about the webkit-qt mailing list