[Qgis-developer] Plans for QGIS 3.0 and QWebView.... *sigh*
Nyall Dawson
nyall.dawson at gmail.com
Tue Sep 13 23:17:00 PDT 2016
Sooooo... now that we're close to cutting off Qt4 I guess it's time to
start this conversation again. What should we do with web views in
QGIS 3.0?
Here's the situation as I see it:
- upstream still hasn't made the new QtWebEngine classes anywhere near
as featureful as the removed QWebView classes. I was hoping by the
time we were ready for Qt5 this would have changed, but there hasn't
been any really relevant changes since we last discussed this.
- the one minor expection to this is a new method which was added in
Qt 5.7 - QtWebEngine::printToPdf [1] . The docs say:
"Renders the current content of the page into a PDF document and saves
it in the location specified in filePath. The page size and
orientation of the produced PDF document are taken from the values
specified in pageLayout."
Potentially we could use this as a roundabout way of rendering web
content offscreen - we could print the content out to a pdf, then
somehow read it back in and render it to a QPainter surface. Maybe. I
haven't been able to test this, but I have extreme doubts. Just
looking at the docs I can't see anyway to control the DPI used for
printing the content to a pdf, and my suspicion is that it will just
be rendered using screen resolution.
Even with the long shot that we could successfully use this method
it's still only available in Qt 5.7, which won't hit our target
platform repos until mid 2029 ;)
- Possibly we could use the revived QtWebKit (see [2]), but we'd
probably need to package it ourselves. Advantages of this approach are
numerous, including no loss of current features.
Given all this... I think our realistic options are:
1 Don't use a web engine. Use QTextDocument and it's limited html/css
support. Disadvantages: we lose the ability to insert rich html
including javascript, etc. Advantages: retain vector outputs and
simple code.
2 Render QtWebEngineView widgets as rasters in screen resolution.
Disadvantages: pixelated, not vectorised and text converted to raster,
requires use of a graphical widget which may cause issues with things
like QGIS server (?). Advantages: can use javascript, videos, etc
My opinion:
QgsComposerLabel - approach 1. Switch to the basic QTextDocument support
HTML annotations - approach 2. These are likely used more often in the
canvas interactively and the loss of resolution when they are used in
composer is less important.
QgsComposerHTML - no idea. Probably option 2 but the loss of
resolution/vector output will really hurt.
It's probably time for us to address this, so we need to make a choice
between these bad options. Any suggestions?
Nyall
[1] http://doc.qt.io/qt-5/qwebenginepage.html#printToPdf
[2] http://qtwebkit.blogspot.com.au/2016/08/qtwebkit-im-back.html
More information about the Qgis-developer
mailing list