Qt4 and Qt*WebKit cleanup?

[a17r]

Qt6 is around the corner. With Qt4 unmaintained for several years and basically not buildable with modern dependencies, Qt5WebKit abandoned for good and in the process of being cleaned up from distributions (Gentoo, Debian Experimental, opensuse TW are leading the way there), are you open to

• raise minimum Qt to 5.12 (at least), clean up related ifdefs in code and qmake/cmake
• port cmake to >=Qt5 only
• try to port the KDE bits to KDE Frameworks 5

I can look into the first two items with PRs, but can't promise to work on the third beyond KDE-provided transition scripts.

[gyunaev]

Yes, this is all planned. However I would only raise the minimum Qt version if truly necessary, i.e. not just "to write one line of code instead of 3". If we can build with Qt 5.6+ (which I think is minimum for QWebEngine) we should be good.

[a17r]

If we can build with Qt 5.6+ (which I think is minimum for QWebEngine) we should be good.

I don't think even a single ifdef is justified for that; if you go through repology listings of qtwebengine versions: https://repology.org/project/qt/versions ...of all the distros, I could find only such as <=Debian 10, <=Devuan 3.0, <=Fedora 27, openEuler 20.03, <=openSUSE Leap 15.1, <=Pardus 19, <=Rosa 2016.1, <=Ubuntu 18.04 with a version lower than 5.12. These are either very old and thus highly unlikely to add any new packages to their repository anyway, or hugely obscure. The overlap with those providing kchmviewer-8.0 today is zero: https://repology.org/project/kchmviewer/versions

If you create a new dev environment per KDE's instructions with KDE Frameworks today you will find it even has a 5.15.2 minimum from several releases back. Qt 5.12 as a minimum makes somewhat sense, as it is the last freely available LTS version that still gets updates from upstream, while Qt 5.15.2 gets frequent backports via KDE's Qt5PatchCollection project. And especially wrt future porting to Qt6, you want to be able to raise minimum QT_DISABLE_DEPRECATED_BEFORE and KF_DISABLE_DEPRECATED_BEFORE_AND_AT levels in cmake.

[brjsp]

As the new opensuse maintainer for this package i'd want to ask: what is KDE frameworks support in this? Is this something i should enable, or is it a Qt4 remnant? Right now, all distros seem to build this with Qmake, and the RPM produced does not have any libKF5* dependencies.

[corvus1]

@brjsp If I remember correctly, it's used for translations, however, the only more or less complete translation is ru_RU, so that's a bit moot.

[brjsp]

@corvus1 Do you know how to compile it so that i can compare the differences?

[u-235]

@corvus1 Do you know how to compile it so that i can compare the differences?

Use CMake for the build. But now it's tied to Qt4 and KDE4.

[brjsp]

@u-235 I have managed to compile kchmviewer with USE_KDE under qmake5. The only difference i have noticed is that the Open dialog now shows network locations. KIO does not actually work tho — I navigated to an ftp and tried to open a chm file and received an error that only local files are supported.

Translations do not work either. Skimming the .po files, they seem to predate some refactor and no longer match the source code.

[u-235]

Hi, @brjsp.

It is not enough to build a project with the USE_KDE option for translations to appear in the application. Additionally, the *.po files *.po must be converted to *.mo. Then the *.mo files must be installed in the right place on your system. The qmake script does not do any of this, unlike cmake.

You're right, the translations are pretty outdated. In my opinion, kchmviewer is the best program to read CHM and it's very strange that the community doesn't update translations.

You're also right that the build with KF5 and USE_KDE adds almost nothing to the UI.

To summarize, at the moment the build with the USE_KDE option is not worth the effort spent on it.

[brjsp]

@u-235 I did run cmake first in the po directory and installed the resulting .mo files into /usr/share/locale! You can see my experiments here. It did not work, because the file names in the .po files refer to source files that no longer exist.

[u-235]

@brjsp, this works a little differently. Source file names in .po files are needed for the translator's convenience, as well as other comments. In general, Gettext only uses the string itself to find the desired translation.

[ghost]

Apologies for barging in.

First of all, just wanted to thank George (@gyunaev) for the continuous work on this project. Had a need for a CHM viewer and couldn't find anything suitable in Mint 19 Cinnamon until accidentally finding a standalone version of kchmviewer shipped with VirtualBox some time ago. Used that version (4.0 alpha) until today when I bit the bullet, started searching for the code, and tried compiling it.

Now, for various reasons some of us may have to stay behind hardware- and/or software wise. I for one will most likely die with Mint 19.2 on this 13+ years old notebook. Thing is, Mint 19 being based on Bionic 18.04 can only go up to Qt 5.9.5 but can also make use of Qt 4.8.7. In fact before finding this updated repository - which compiles v8.0 just fine with Qt 5.9 - I had tried older 7.7 and 7.5 versions at SourceForge, and they also compiled fine^[1] with Qt4.8 on this machine.

As such I would kindly ask you to keep compatibility with the Qt 5 version available in these slightly older but not decrepit OS versions such as Mint 19/Bionic 18.04. Thank you.

[1] Actually there was some issue with a pro file that had to be modified before getting v7.7 to compile but it finally did.