Port to Qt 6

[gruenich]

It is not obvious that Qt is a dependency. It is not obvious if Qt 5, Qt 6, or both are supported.

A proper check needs to be added to the CMakeLists.txt.

[shundhammer]

Right now, it's Qt 5, but in the not too distant future it will have to be Qt 6 since Qt 5 is already announced to be end of life in early 2025.

If anybody feels like taking care of the CMake part, PRs are welcome; hopefully while keeping it reasonably understandable.

CMake is a nightmare, and the documentation completely sucks. There are no useful examples, and stuff gets deprecated and massively changed between versions. Every time I have to touch that stuff, I keep screaming at my computer.

[gruenich]

I am going to have a look. Some things like deprecations and QRegExp move can be made prior to the Qt 6 move, to reduce the number of changes to be reviewed at once.

[shundhammer]

I know about those deprecated warnings; IIRC I even switched some of them off because otherwise they flood the build output.

For QDirStat, that was a problem because some of the changes were incompatible with older Qt versions, and I wanted to keep it available for older distros with older Qt versions. For this project, this should not be an issue; the target distros are Tumbleweed / Slowroll and Leap 15.6 (which implies SLE 15 SP6, too).

[shundhammer]

Having said that, parts of the code (most YQPkg* classes) go back ~20 years, so some issues might come up; but I am confident that they are reasonably easy to fix. In the worst case, some of them might need a major rewrite like I just did with YQPkgSearchFilter.

That's also the reason why I went over all of them in the last few days to get at least the largest pieces of bit rot and part-time maintainer neglect and misuses fixed; it clearly showed that too many people were changing stuff that they never really understood: Segments of code disabled with #if 0 ... #endif speak volumes. ;-)

[gruenich]

I can add with a pretty limited understanding of the domain, C++ and Qt.

I am active in writing CMake code, modernizing C++ projects, fixing compiler and deprecation warnings, and using modern C++ idioms.

I created a proof of concept for Qt 6. Not yet ready to be merged, but a start. See #27.

[shundhammer]

This is done in the qt6-port branch.

There are still some quirks to be fixed, but in general, it's working and beginning to look good.

But see #78 for building and development on Leap 15.x and the joys of using CMake and hammering it into shape to use a suitable C++ compiler that supports the C++ standard that Qt 6 needs.

[shundhammer]

The qt6-port branch is now merged to master. The Qt 6 version is now released as Myrlyn-0.9.2.

[gruenich]

I am glad it got merged, thanks! The only downside it, the change is not visible.

[shundhammer]

There are very subtle changes: The SVG icon for "download finished" now appears in its real colors, i.e. a middle grey "download" part on the left side and a black checkmark. In Qt 5, it was rendered all black.

Not really earth-shattering, but I had really meant to make the left part a bit faded out to indicate that it's a previous download, not the current one.

Other than that, the looks are very much the same; of which I am actually glad. On my laptop, my first impression about the Qt 6 version was "damn, this looks like shit!" - see #79. At that point, I hadn't gotten it to build yet on my desktop machine because that one has Leap 15.6, and there was #78. So I was fuming: All that work for mushy looks because of yet another iteration of HiDPI handling (I lost count how many times they changed that over the years), and would I get it to build on Leap 15.6 at all? Or would it only be available for Tumbleweed and Slowroll?

I fought CMake, all the different compiler versions, Qt 6, HiDPI stuff, rpmlint (#80) and OBS a lot over the last few days. It was like fighting alone against the united ork armies of Sauron.

But I won. Sauron is dead, and the ring is in the volcano. And I still have all my fingers. 😃

Read the GitHub issues here for some more backstories, including #1 and the botched Git tag (9.0.1 instead of 0.9.1).

And of course many thanks to you and your contributions!

[shundhammer]

Of course, what's most important is that now the project is future proof for the next couple of years with a Qt version that will receive support. Qt 5 served us well, but it's on its last legs.

There will be community support (so I was promised), and we as SUSE will have to support it for quite some more years as long as SLE-15-SPx is alive:

https://www.suse.com/lifecycle/

• SLE-15 SP6: General support until 2031-0-31; long time support until 2037-07-31
• SLE-15 SP7: Not released yet; expect end of life one year after SP6.
• SLE-15 SP8: Will there be one? I don't know.

...and then the end of time will arrive anyway, at least the end of time_t: 2038-01-19 when the seconds from 1970-01-01 00:00 will overflow in a 32 bit unsigned int. 😄

[gruenich]

Yes, to become future save, that was my main motivation to work on the Qt 6 port.