Migrating QDirStat to Qt6

There seem to be a number of developers who want to see QDirStat being migrated to Qt6. Some of them even created pull requests for that. So let's discuss this.

End User Benefits

So far, I haven't seen any. Do they really exist? There is talk about performance improvements in certain areas; but I couldn't tell any difference between the same program running with Qt6 vs. Qt5.

End User Problems

• Automatic HiDPI scaling. That sounds like a benefit, but actually, it can turn the rendering into pixel mush; I have personally experienced this here.

  Yes, there are workarounds; but seriously, why would I as a user need workarounds for problems that shouldn't even exist? Maybe it works better in true HiDPI like a 4k display. But on my 128 dpi 14" laptop, it simply looked like shit; that was my very first impression after that particular Qt6 port.

From the Developer's Perspective

• CMake is the official development environment. I hate CMake, and I have good reasons for that. In my programming career (1986 - 1991 as a computer science student, 1992 - today as a professional software developer) I worked with many build environments; plain Make, AutoTools (AutoConf, AutoMake, LibTool), QMake, Ruby Rake, OBS, CMake and a dozen or so custom-made ones. They all have their quirks, but CMake has the most.

• The much simpler QMake is still there, but probably on its way out. What a pity.

• They made an effort to make a developer's life miserable, even beginning with Qt 5.15 which they saw as a preparation for porting applications to Qt6. Well, great move: You can either compile for older versions which are still around, or become incompatible to Qt5 when going down the "prepare for Qt6" route.

• Case in point: Qt::endl and the need for a new logger if you don't want to bow down to the forced code ugliness that this Qt::endl brings along.

• Some things are different in Qt6, so a lot of code needs to be adapted. QRegularExpression instead of QRegExp is just one example. Some class methods are no longer virtual, so you can't override them. Some things behave differently. It's not smooth sailing to port a nontrivial application from Qt5 to Qt6. I'd bite that bullet if there were real tangible benefits for the end user. But... see above.

What's the Hurry?

Yes, Qt6 has been out for quite a few years now, and Qt5 is getting long in the tooth. But realistically, Qt5 still has a lot of life left in it. A lot of applications are written in it, and while many have already been migrated to Qt6 (e.g. KDE Plasma and its applications), others have not.

And most Linux distributions will need to keep Qt5 around for the forseeable time anyway because of the existing code base. Just think about ancient GUI toolkits like Tcl/Tk (the old ugly grey mid-90s style applications) still being omnipresent. Some stuff is just impossible to get extinct.

So, will some very fast-moving Linux distros manage to get rid of Qt5? Arch Linux maybe? They can try, but frankly, I think even they will have to keep it around for many years to come.

But the Children End Users, just think about the Children End Users!

Well, yeah, because the end user benefit was... errm... see above.

Can any end user even tell the difference between a Qt5 and a Qt6 application? I don't think so. Same with Qt4, by the way.

Current Obstacles for a QDirStat Qt6 Migration

• Need a new logger; same as here in the Myrlyn software package manager, my current other Open Source project.

  For that project, I imported the QDirStat logger (which worked well), and I managed to port it from using a QTextStream (which brings that damn Qt::endl problem with Qt6) to std::ostream. I spent many hours to re-import it to QDirStat, but that fails with the craziest C++ compiler errors; it refuses to use my operator<<( ..., const QString & ) which works great in Myrlyn. See branch huha-new-logger if anybody wants to give it a try.

And no, a #define ENDL Qt::endl is not a viable solution.