[webkit-qt] Extending Qt's QML WebView feature set
simon.hausmann at digia.com
Fri Nov 2 02:43:46 PDT 2012
On Thursday, November 01, 2012 07:36:46 PM Jan Kundrát wrote:
> I'm using the WebView QML component in the Harmattan version of my IMAP
> e-mail client called Trojita . The WebView component is used for
> rendering of actual e-mails, so I need quite an amount of control over
> how the webkit underneath operates.
> In Qt 4.7 (which ships on Harmattan), I had to basically maintain a fork
> of the QDeclarativeWebView class, see  for how it looks like. The
> changes I needed were:
Smart move :). It paid off that the QML webview was developed only using public
> 1) Make the QWebSettings property available to the QML code, and publish
> the userStyleSheet property through that. This was needed to make the
> WebView render things in white on black background , a theme which is
> used throughout my application.
> 2) Make it possible to provide a custom QNetworkAccessManager for each
> WebView instance. This is very important for various reasons I outlined
> in  -- in short, each e-mail being displayed must not access the
> network without an explicit user's acknowledgement for privacy reasons.
> It can also only ever have access to a single IMAP message at a time. In
> order to support a use case where multiple messages are open at once,
> one therefore has to use two distinct QNAM instances, one for each
> WebView, which makes QDeclarativeNetworkAccessManagerFactory not
> suitable for this job (apart from any possible threading issues). My
> patch makes it possible to use a QNAM subclass provided by the user's
> C++ code.
> The patches will have to be cleaned up (they're against a 4.7 release of
> Qt, for one thing, and use Trojita-specific naming to prevent any
> clashes as well). I am not familiar with Qt5/WebKit release plans and I
> also don't like wasting time preparing patches which nobody would
> accept, which is why I'd like to ask here -- would you guys accept
> patches adding this functionality? And what's the probability of them
> being included in Qt 5.0?
In my opinion we shouldn't add more features/API to Qt 5.0(.0) at this point,
so the earliest would be Qt 5.1.
I think it would indeed be very desirable to support your use-case but I
suggest to focus on the QML2 API for enhancements, in order to benefit from the
responsiveness of WebKit2 (and hopefully sandboxing in the future).
Zeno has spent some time earlier this year looking at how to do the kind of
network access manager integration with WebKit2 that would be required for
example for an email client. With WebKit2 there's no possiblity of just
providing another QNAM instance due to the process separation. However the
concept we came up with is to allow for the application to install delegates
for network requests of a particular scheme. That would allow for feeding the
HTML email into WebKit and installing a scheme handler for example "cid:" to
allow for processing these kind of references for HTML emails.
With regards to external network access I think this should be more or less a
setting. Together with the user stylesheets, which I agree are a very useful
feature to have and is missing right now from the public (QML 1+2) API.
I'd like to sit down some time after Qt 5.0 is out to
(1) Sort out which APIs from experimental we can make public and supported
and which ones we should remove. The scheme delegation is a good candidate for
something that we should support and IMHO we should have a simple example in
the Qt 5 qtwebkit-examples-and-demos module that demonstrates it. Perhaps
using a simplistic pseudo email client as example :)
(2) We would also have to sort out how exactly we're going to deal with
"preferences". There are different kinds, ones that are entirely development
specific (network access, user stylesheet, kerning/ligatures, etc.) and others
that are much more user visible (font choices, etc.). In the WebKit1 API we
put both together and ended up with a huge amount of settings which included
many things that should not be settings but just work out of the box.
The KDE project has many beautiful sprints during the year for sub-projects to
allow for efficient discussions and decision making. Perhaps we should try to
see if we can have a similar sprint for QtWebKit early next year somewhere in
central europe (Berlin? ;-).
More information about the webkit-qt