Converting codebase to Qt 6

[kemier]

macOS m1 version:12.6

compile error in 3rd party code:

In file included from ../3rdParty/qxt/qxtglobalshortcut.cpp:1:
In file included from ../3rdParty/qxt/qxtglobalshortcut.h:34:
../3rdParty/qxt/qxtglobal.h:200:19: error: allocating an object of abstract class type 'QxtGlobalShortcutPrivate'
        pvt = new PVT;

so is it ready for the compiling of new version qt?

[nuttyartist]

Hi! No, the code is not fully compatible with Qt 6 yet. I wonder if it's worth converting our codebase to Qt 6?

[bjorn]

I wonder if it's worth converting our codebase to Qt 6?

Well, it basically has to be done because Qt 5.15 is no longer maintained for open source users (or at least no binaries are released beyond 5.15.2) and even standard support will end in a few months.

[txtsd]

It's worth making the codebase compatible with Qt6 now instead of later. Migrating from qmake to cmake is also recommended at the same time.

[nuttyartist]

Sounds like a good idea to me.

[zjeffer]

I'm working on a QT6 port here: https://github.com/zjeffer/notes-qt6

I managed to fix some build errors just by looking at documentation and updating the code. There are many errors left to fix. I noticed the 3rdParty code also isn't QT6-compatible, should we fork and update those projects as well? Or look for replacements?

[nuttyartist]

That's awesome. If you find some 3rd party libraries that fit the bill, suggest them here. But maybe forking is better since we already incorporated and battle-tested them in production?

[zjeffer]

I will investigate which ones can be easily forked.

As for the main project, do we need to add a version check for every change, so that everything still works with QT5, or should we move completely to QT6?

[nuttyartist]

My opinion is to move completely to QT6. What about others? @bjorn?

Since with self-contained packages there is no problem, what about when distributing our packages as .deb for example, let's say Ubuntu systems with older versions of Qt, will the package manager know the right dependencies to install?

[bjorn]

My opinion is to move completely to QT6. What about others? @bjorn?

Well, you need to decide what is the minimum system you'd still like to support. When Notes needs Qt 6, then your users will need at least macOS 10.14, Windows 10 or Ubuntu 20.04.

For Tiled I recently raised the minimum supported Qt from 5.6 to 5.12, which allows still supporting macOS 10.12, Ubuntu 16.04 (in theory, though I think my builds need 18.04) and Windows 7, but no longer Windows XP.

Regarding the porting, @zjeffer, I think it would be good to do it in two steps. The first goal could be to disable all API that got deprecated before Qt 5.15 (by defining QT_DISABLE_DEPRECATED_BEFORE=QT_VERSION_CHECK(5,15,0)). That way, we can continue using Qt 5 while already doing a large part of the preparation for Qt 6. Actually making everything work with Qt 6 will be enough work in itself, even after this preparation. And then we can also judge better if we can still support Qt 5.

[nuttyartist]

I didn't know that QT6 only works on these platforms. I would definitely still want to support the same platforms you support with Tiled. So maybe we can have two versions, for now, QT6 for recent platforms and QT5 for the older ones.

@bjorn The rest of the tips are sound.

[danfe]

I recently raised the minimum supported Qt from 5.6 to 5.12, which allows still supporting macOS 10.12, Ubuntu 16.04 (in theory) and Windows 7

This is the right thing to do. Most distributions had already caught up to Qt 5.12 and even with Qt6 available, Qt5 is still being default Qt version e.g. in FreeBSD.