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
<[email protected]> wrote:
On Tue, Mar 27, 2012 at 3:05 PM,<[email protected]> 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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
--
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
