packages still compiled against qtwebkit instead of qtwebengine

ostroffjh · 2020-12-25 23:52:19

QTWebkit has been deprecated for years, replaced by QTWebengine. As far as I can tell, both kmymoney and libalkimia are still being compiled against QTWebkit (and QTWebkitWidgets). I don't know that this is appropriate for a bug report, but figured it should be an Arch wide decision to migrate at some point. Any suggestions on where I should look for such a discussion (I've done some searching, but not found anything relevant) or where to suggest such a change?

Scimmia · 2020-12-25 23:57:04

It's not Arch's decision, it's upstream's decision. If they don't program it against qtwebengine, it's not going to work.

ostroffjh · 2020-12-26 01:20:37

I know that both KMyMoney and libalkimia can be (and prefer) compiled against QTWebengine instead of QTWebKit. It's a cmake option for both of them.

Trilby · 2020-12-26 02:35:15

Do you have any references for that? I certainly don't see how upstream can "prefer" Webengine as the PKGBUILD for what is in the repos does not explicitly specify either rendering engine, so what is used is what upstream has set to be the default in the absence of a some cmake flag overriding that choice. Further, the upstream documentation here does not show any such options for cmake (though that documentation does seem to be lacking overall).

EDIT: I see options are available in the CMakeLists.txt of both projects, but the default is webengine in both cases, and libalkimia further flags webengine support as experimental.

Last edited by Trilby (2020-12-26 02:43:16)

ostroffjh · 2020-12-26 02:46:45

I do documentation for KMyMoney, and yes, the docs (especially that build page) are rather out of date. I will certainly suggest to the developers to change the default from qtwebkit to qtwebengine, but all that is needed ffor KMyMoney is to add -DENABLE_WEBENGINE=TRUE to the cmake invokation. I'm pretty sure the same is true for libalkimia, although it's been a while since I've had to build it myself. I'll try to get a definitive statement from the KMM devs and report back. (There is an overlap between KMM and alkimia devs, so a response will hopefully apply to both.)

Separately, given how long QTWebkit has been deprecated, I would hope package builders would consider starting to switch, as long as it only take something as simple as that cmake parameter, even if upstream has not switch the default yet. I'm certainly not suggesting packagers go to any significant effort to make the switch, but sometimes it's only pressure or feedback from packagers that gets upstream to update outdated defaults.

Xyne · 2020-12-26 02:54:26

The best solution is to contact the upstream developers and ask them to switch the default build options to QTWebEngine. Those changes will automatically propagate to the Arch packages. If upstream ignores the request or refuses and the package fully supports QTWebEngine in its documentation, you can make the argument to the package maintainer that using WebKit is a security issue. Security issues may be important enough to override default options in packages. Whether or not the vulnerabilities of WebKit constitute enough of a threat to merit the change is up to the package maintainer.

edit
I only saw your previous reply after posting.

Last edited by Xyne (2020-12-26 02:55:43)

ostroffjh · 2020-12-26 03:21:34

Crossing in the ether....
As far as I can tell, QTWebkit has been deprecated for years, and is no longer supported by Qt. However, I'm getting very confused trying to track down any definitive statement to that effect. Most pages I find on qtwebkit have not been updated in four or five years, but I know that's not definitive.
I'll post back when I have a response from the KMM devs.

eschwartz · 2020-12-28 02:11:18

qtwebkit is kinda-sorta-maybe a little bit maintained.

@annulen gave it life support via the update to 5.212.0alpha4 and maybe there will even be another update someday... https://github.com/qtwebkit/qtwebkit/ does get some development work. Though I think @annulen is essentially the only person who ever commits to it these days. But it's not *dead*.

OTOH browsers are terrible, and webengine is more terrible in that sense than webkit. You cannot start webengine from a QApplication on demand, only beforehand during startup, but it's wastefully resource-hungry about it. It's quite difficult to build on anything other than Windows, macOS, or glibc Linux (x86 or arm only IIRC)... which locks out *BSD as well as various musl distros or PPC ports etc. And it imports the "chromium problem", whereby the FSF is convinced it's not free software due to outstanding license concerns and "shady code" and whatnot, and blacklists it, webengine, and electron from FSDG operating system distributions.

The option to build with webkit is valuable to at least Parabola (the arch derivative). And on pure resource usage considerations, it's "better" that way. Though it would be even better to use QTextBrowser, if you only need rich text and not all of HTML5+js. Though I genuinely have no clue what kmymoney or libalkimia are, merely that "lots of stuff" frivolously uses browser engines for no good reason (e.g. often to display help manuals instead of using an online one in the browser).

On the other other hand, if webkit continues to see as slow development as it has now, no one will be able to justify packaging it anymore, and webengine it will be...

On the other other other other hand, obviously strong preferences from upstream should hold a lot of weight, and if it didn't require non-default options to switch from looking for webkit to looking for webengine, we'd even believe those strong preferences exist. So definitely get on top of that if you've got upstream pull.

ostroffjh · 2020-12-28 03:46:33

Ouch. That will take me a while to digest. KMyMoney is a personal finance manager (I do docs, not programming) but my understanding is that it uses webkit/webengine for layout of reports, so we likely don't need the full browser/js stuff. I'm not actually sure what libalkimia (and underlying library for financial fucntionality (yes, I'm being vague, as I don't have a better answer now.) However, as a KDE application, I'm not sure what contraints there are. I'll certainly ask the developers about whether using QTextBrowser would be sufficient.

eschwartz · 2020-12-28 05:32:20

https://doc.qt.io/qt-5/richtext-html-subset.html FWIW. It's often reasonable to restrict oneself to this fairly decent HTML subset rather than something that eats your RAM ad battery, pins your CPU and prevents sleep/suspend... and as a bonus it's all in QtWidgets (qt5-base) and therefore doesn't drag in another 150MB of qt5-webengine dependencies.
Handy for doing {win,mac,linux}deployqt prebuilt installers and keeping down the size, and especially handy if you have a Windows port, since Qt officially supports Windows 7, but qt5-webengine itself is on a different support lifecycle and only supports Windows 8/10 (to the extreme dismay of many https://calibre-ebook.com/ users, as I've personally seen).

If it's only being used for layout, it's likely possible to get away with "Rich Text" instead of "browser".
The programs I have on my system that use qt5-webengine are, all 3 of them, using it for EPUB spec compliance and thus need the complete range of possibilities the browser permits, so that is unavoidable...
One other program optionally supports previewing markdown documents in webengine or QTextBrowser and doesn't hard-require the former.

Last edited by eschwartz (2020-12-28 05:38:50)

Arch Linux

#1 2020-12-25 23:52:19

packages still compiled against qtwebkit instead of qtwebengine

#2 2020-12-25 23:57:04

Re: packages still compiled against qtwebkit instead of qtwebengine

#3 2020-12-26 01:20:37

Re: packages still compiled against qtwebkit instead of qtwebengine

#4 2020-12-26 02:35:15

Re: packages still compiled against qtwebkit instead of qtwebengine

#5 2020-12-26 02:46:45

Re: packages still compiled against qtwebkit instead of qtwebengine

#6 2020-12-26 02:54:26

Re: packages still compiled against qtwebkit instead of qtwebengine

#7 2020-12-26 03:21:34

Re: packages still compiled against qtwebkit instead of qtwebengine

#8 2020-12-28 02:11:18

Re: packages still compiled against qtwebkit instead of qtwebengine

#9 2020-12-28 03:46:33

Re: packages still compiled against qtwebkit instead of qtwebengine

#10 2020-12-28 05:32:20

Re: packages still compiled against qtwebkit instead of qtwebengine

Board footer