This reverts commit 643f4a5726 and finishes the task of adding WebEngine as an
alternate backend to be used in printing.
The ultimate goal is to be able to build without QtWebKit (as that is no longer
supported in Qt6). WebKit was used in two places: The user manual and printing.
This patch makes printing work with WebEngine.
The main obstacle is that WebEngine no longer allows accessing HTML elements
from C++ code and rendering the page to a QPainter.
The old version used this to figure out dimensions and page breaks for the
pages and then in the QPainter placed the profile images. With WebEninge, you
need to access the elements using JavaScript which is now used to place the
profile in the html proplerly as an <img> tag. To this end, both html and
profile images are written to a temporary directory on disk.
This image replacement by JavaScript is only necessary to make old templates
still work. It could be replaced by actually putting <img> tags in the
templates (but this would break user edited templates).
In my experiments, the page breaking was done great by html/css, so the
additional magic seems superflous.
What remains to be done:
* remove empty page at the end of printout
* make preview great again (in particlar needed for template editing)
Note: since QtWebEngine currently cannot be built with our toolchain on
Windows, this patch keeps QtWebKit support around by making the QtWebEngine
compile-time conditional via #ifdefs.
[Dirk Hohndel: merged a few commits to make this more logical - the resulting
commit is fairly big, but IMHO preferrable]
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Printing never worked, none of this was ever included in test builds. Also, now
that there are official releases of QtWebKit again, this just doesn't seem worth
carrying along anymore.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Set an "automatic" mode via parameter (or auto detected if running in
travis environment) to skip the user prompt.
Install the built binary, in automated builds, under the usual
INSTALL_ROOT folder.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Till now we have been building against a previous built of subsurface.
This was handy and fast, but there is a huge drawback in this approach
because we were including a lot of unneeded dependencies (e.g. marble
or serial-ftdi), some of which are, indeed, optional.
With this patch, a stripped down version of susbsurface is built and
used to link in smtk2ssrf.
The bad news are that this - almost unusable - version of subsurface
overrides any preexisting binary, so the user has to rebuild.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
