Understood, thank you for the explanation. That helps, and also brings up another question.
On the debian/rules architecture selection, yes, this is supported. Something similar to: ifeq (ppc64el,$(DEB_HOST_ARCH)) # cmake without webengine else # cmake with webengine endif should work. However, the explanation of the renderers does bring up a privacy / security question. I would personally consider the lack of Javascript support a plus, in that it stops pingback or similar tracing / monitoring to third party servers. Loading up an entire Chromium instance without being able to turn off external access, disable Javascript execution, etc. seems like a major security and privacy risk. As an example of how I would expect to see this handled, VLC pops up a warning indicating that third party services will be able to see what media you are playing when you turn on metadata lookup -- it seems that if we're going to use QWebEngine for rendering, a similar popup should be displayed somewhere indicating that we're loading and executing the Web pages including all of the tracking and monitoring pingbacks. I bring up the privacy issues because I would be tempted to disable QWebEngine across all architectures on those grounds alone, but it's not my call. Building without QWebEngine on ppc64el would be enough to close this bug. Thanks! ----- Original Message ----- > From: "Jean-Francois Dockes" <[email protected]> > To: "Timothy Pearson" <[email protected]>, "1111324" > <[email protected]> > Sent: Sunday, August 17, 2025 3:22:09 AM > Subject: Re: Bug#1111324: Acknowledgement ([regression] recollgui > uninstallable on ppc64el) > Recoll uses an HTML engine for displaying the result list and the preview > window. > > There are three possible engines: > - QTextBrowser, which is the Qt native HTML engine > - Qt Webkit > - Qt Webengine (chromium-based) > > Of the 3, Qt Webkit was by far the best for our usage, with a much better API. > > Qt decided that they needed to switch to using the chromium version, probably > because of > better Web "standards" support, mostly for people who actually use it for > implementing a > Web browser. > > Qt Webkit was externally maintained for Qt5. As far as I know, there is no Qt6 > implementation, so there is no way ahead for it. > > QTextBrowser has only incomplete support for CSS styling (and no Javascript > which is an > issue for some result list customisations). Attaching a preview of the > wikipedia > front > page with QTextBrowser (on the left), and QWebengine (right) for illustration. > > For the moment, it is still possible to build with qt5 and libqt5webkit5, > which > is > probably the best current solution, but it has no future. > > Is it possible at all to use different rules for different architectures ? > Disabling the > "real" HTML engines only for architectures platforms which don't support them > would > probably be the best approach going forward. > > jf > > > > > [image/png:recoll-wikipedia-preview.png]
