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 [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
