[Qgis-developer] Plans for QGIS 3.0 and QWebView.... *sigh*

Mathieu Pellerin nirvn.asia at gmail.com
Wed Sep 14 00:04:58 PDT 2016


Nyall,

IMO, this item (QgsComposerLabel - approach 1. Switch to the basic
QTextDocument support) should be applied, irrespective of the QWebView
situation. I have never expected to get full-fledged html support when
checking the render as HTML, especially since we have an HTML element
alongside labels. Also, when the label item shares code with the labelling
engine, the need for html rendering will be greatly reduced (i.e., no more
need for it when in need of text shadow, outline, etc.).


On Wed, Sep 14, 2016 at 1:17 PM, Nyall Dawson <nyall.dawson at gmail.com>
wrote:

> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160914/a3d91d32/attachment.html>


More information about the Qgis-developer mailing list