Moving post Qt 5.15.2 / Support for Qt6

[hoffie]

Hi,

as per my understanding, 5.15.2 is the most-recent Qt Open Source release, while references to some newer versions (even 5.15.10?) appear in some places. As I understand it, those newer releases will no longer be available under open source licenses. In addition, I don't think there are plans for another Qt 5.x release (e.g. 5.16).

Relying on 5.15.2 for Jamulus will cause problems in the short and long run:

• New Operating System releases may become slowly incompatible with Qt 5.15.2 and bugs may be introduced outside of Jamulus, but may affect Jamulus users. My gut feeling is that this may have already happened with the (event handling-related?) memory leak issues on Mac Big Sur (Jamulus 3.7 hangs -eventually- on Mac Big Sur #1791). This may even become worse. Some more examples:
  • https://bugreports.qt.io/browse/QTBUG-85546
  • https://bugreports.qt.io/browse/QTBUG-85279 (Apple M1 support)
  • https://forum.qt.io/topic/121450/issues-with-qt-on-mac-os-10-11-big-sur
• Builds which ship with bundled (or static) Qt (e.g. Windows and Mac) may contain security vulnerabilities which we cannot fix
• Linux distributions might eventually phase out Qt5 in favor of Qt6 (although I suspect that this will still take years)

Background:
https://www.phoronix.com/scan.php?page=news_item&px=Qt-5.15-LTS-Commercial-Phase

I'm aware of the following options:

1. Move away from Qt -- someone suggested this recently. Realistically, this would imply a rewrite of most of Jamulus as we depend on Qt in all places, from GUI handling to network stuff (well, as expected, for a cross-platform framework).
2. Make Jamulus Qt6 compatible. IMO, this is the only viable option. I had a first stab at this some weeks ago and there is some low-hanging fruit which is easy to fix. I stopped when running into more and more errors. I cannot judge how much work it will be. We would certainly benefit from someone who is very very familiar with Qt and/or has already converted projects from Qt5 to Qt6 (while retaining Qt5 compatibility for now!).

As soon as Jamulus works with Qt6, we should start building Mac and Windows binaries with this version.

@jamulussoftware/maindevelopers Any opinions? Is someone already working on such things?

Kind regards,
Christian

[atsampson]

While it'd certainly be good to make Jamulus work with Qt 6 in the long run, Qt 5 updates after 5.15.2 are being made available for open source packagers by the KDE project.

[hoffie]

Qt 5 updates after 5.15.2 are being made available for open source packagers by the KDE project.

Good point, yes. If we were to rely on that it would require us to build Qt ourselves for Mac/Windows, though. Those patches may also be less focused on Mac/Windows, as KDE primarly targets Linux/BSD, I assume?

[ghost]

I don't think the MacOS tail should wag the Jamulus dog. Focus should go to supporting the Raspberry Pi. That way you can afford a World-friendly platform on a budget (especially if you always own the latest Apple$ or Window$).

[ann0see]

Oh. Ok. Did you find any issues on Raspberry Pis? If that's the case, I think, we should discuss it in a separate discussion.

[dcorson-ticino-com]

?Scratching head?
Why would I want to purchase a Pi if I already have an Apple or Windows PC ?
For those who only have a cellphone, OK, but otherwise?????

[ghost]

Jamulus 3.6.2 is available, so making the lastest version should be possible.
https://mirrors.sohu.com/raspbian/raspbian/pool/main/j/jamulus/
I'll have to get a Raspberry Pi

If anyone has a Raspberry Pi, please test Jamulus and tell us.

[hoffie]

Jamulus is used on Raspberries by lots of people. The only missing thing is official autobuilds. This is tracked in an issue, along with the challanges involved: #1452

This topic is unrelated to the Qt discussion though :)

[ghost]

?Scratching head?
Why would I want to purchase a Pi if I already have an Apple or Windows PC ?
For those who only have a cellphone, OK, but otherwise?????

If Apple changes its interfaces or policies every six months, Jamulus will at least be available on the Raspberry Pi.

[pljones]

I think we should move off Qt, myself.

Any future direction should look to

• use a Controller/Service model to divide up the application code, with a clear API exposed by the Service layer
• minimize the amount of (ideally eliminate) framework-specific code used within the Service layer

The goal being to allow the Controller layer to be replaced relatively easily (e.g. headless mode with "remote control" through MQTT, or via a web server / browser, etc).

Of course, both parts are large pieces of work.

[dcorson-ticino-com]

I am wondering if Qt6 will relieve us of the Mac problems or not.
It looks to me that there will be a lot of work, for example C++17 no longer understands enum which means changing them all too class, etc. And that is probably the easy stuff.
When we have 3.8.0 out the door I will spend a day and see how far I can go to get us up on Qt6.
Qt6 will also force some updating too, not less than macOS 10.14 or Ubuntu 20.04 for example.

[npostavs]

for example C++17 no longer understands enum which means changing them all too class, etc.

Wait what? There's no way that's true, is there? I'm pretty sure the C++ standards committee people don't make major compatibility breaks like that.

Looking at https://en.cppreference.com/w/cpp/language/enum I think C++11 introduced enum class, but plain enum should still work.

[dcorson-ticino-com]

As I understood what I read last night enum class was introduced in 11 and enum is no longer supported from 17.
(But it was at 1AM in the morning so maybe I didn't catch all the details.)
In any case Qt6 or the compiler complained about every enum it saw.

[dcorson-ticino-com]

@npostavs you are right. There was only one enum that had to be changed to an enum class. All the other are OK. Don't ask me why.

[hoffie]

I was able to reduce the required enum changes again, even that one enum no longer has to be an enum class. I did that because using enum class seemed way more complicated for one of the unresolved compatibility changes: We would have to register that class with the Qt Meta Type system (?). So I'm glad it works with even less changes. :)

[hoffie]

Based on all the work by @dcorson-ticino-com's and additional improvements by @softins I've gone ahead and created an updated branch, diff: https://github.com/hoffie/jamulus/compare/hoffie:QRegularExpression-missing-include..Qt6-hoffie
Artifacts are currently available from: https://github.com/hoffie/jamulus/actions/runs/1745187738

Recent changes:

• All temporarily dropped features / code-paths have been reinstated (some enum-related changes in the recorder, some Mac-specific code for dock badge handling, Mac legacy builds and Windows 32bit builds stay on Qt5, Linux anyway)
• Re-based on latest master

Next steps:

• Clean up history (we should neither squash nor take it verbatim)
• Actual testing on Windows and Mac (I have solely tested on Linux where both Qt5 and Qt6 run fine)
• Maybe split into separate PRs to simplify review and testing

[softins]

I have rebased my branch Qt6-merged to today's master, and done a comparison with Qt6-hoffie, which appears to be based on the master from before the QRegularExpression merge, but includes it too:

git checkout Qt6-hoffie
git diff Qt6-merged

or

git difftool Qt6-merged

I can see there are quite a few extra things you have added, but it's worth doing a comparison.

Not sure about splitting into separate PRs. That might just be more cumbersome.

[hoffie]

I have rebased my branch Qt6-merged to today's master, and done a comparison with Qt6-hoffie, which appears to be based on the master from before the QRegularExpression merge, but includes it too:

Cool! Yes, I based my PR on that branch because those changes were needed anyway (they caused build errors otherwise). I've now rebased on master as well, so this part should be identical.

I can see there are quite a few extra things you have added, but it's worth doing a comparison.

Yeah, I will have a look again as well.

Not sure about splitting into separate PRs. That might just be more cumbersome.

Hrm ok. I'll at least make them separate commits and will try to distinguish the controversial parts (maybe Qt6 compatibility vs. Qt6-in-releases).

[hoffie]

I have opened #2299 for Qt6 compatibility and #2300 for moving our Windows 64bit and macOS builds/releases to Qt6. Most of the further work will likely be discussed there.
Feel free to ask any Qt6-related questions in this discussion thread though.

[ann0see]

Just built Jamulus via a self compiled version of Qt 5.15.3: https://github.com/ann0see/jamulus/releases/tag/r3_8_2dev_qt5153