[Building/Packaging] Qt 5 support is broken

[sebojolais]

Describe the problem

The commit 627c1dd introduces setAutoAcceptChildRows() that begins since Qt 6.0.

So we can not build OB with Qt 5 now.

[kaamui]

Hi @sebojolais

I'm not sure what to do about that. As discussed a few weeks ago with @letsfindaway, we can make it compile of course using preprocessor directives, but the user experience will be very bad, the feature being quite unusable imo without this flag.

A good option would be to disable entirely this feature in the Qt5 build, but it introduces a lot of code for a version of Qt that probably should start to be deprecated, as it is no longer supported by Qt (https://www.qt.io/blog/extended-security-maintenance-for-qt-5.15-begins-may-2025).

What's your pov ?

[sebojolais]

It seems there are another issue with Qt5 and the Shortcut manager in the Preference dialog.

So maybe it is time to say goodbye to Qt5.

Which issue will be created by the end of the support of Qt5 ?

[kaamui]

Which issue will be created by the end of the support of Qt5 ?

Sorry I didn't understand your question.

[sebojolais]

Is there any issue if we stop the Qt5 support ?

I have not every use-case in my mind.

[kaamui]

The main issue is that it forces every people creating their own version to migrate from Qt 5 to Qt 6, if they want to benefit from the changes coming with each new release. If for some reason it is not possible for somebody to do this migration, it will clearly represent a blocking issue for this person.

For example, for now, there is no Qt6 solution for the known issue around html5 select not placed correctly in html widgets. The workaround working for Qt5 is not working in Qt6. The best we can do is to mitigate it by changing the html5 select by custom objects in our applications and interactivites, but it won't resolve it for apps created on the fly from urls.

Official releases 1.7.4 and 1.7.5 are already built with Qt 6.9

[sebojolais]

I can work on Qt5 support and privide a PR just to continue the compilation with Qt5 if you want.

[kaamui]

I don't think we want to maintain further the Qt 5 support officially, unless it is very detrimental to a lot of people, and we start receiving a lot of complaints about it. if so, I'll be glad if you can share this support with the official repository via PRs

At this point, my idea is to pin an issue where I "announce" that Qt5 will no longer be supported with next version 1.8.0. When 1.8.0 is released, I'll remove mentions of Qt5 in the readme, and we will probably start to remove all the "#ifdef Qt5" from the code.

But I want this support drop to take time, so people actually have time to handle their own Qt 5 to Qt 6 migration.

[letsfindaway]

I would also recommend dropping Qt 5 support for the further development behind 1.7.x. Supported distros without Qt 6 include Debian 11 and Ubuntu 22.04. Debian 11 is supported until 31.08.2026, Ubuntu 22.04 is supported until June 2027 (provided you don't pay extra money for even longer support).

If I assume that OpenBoard 1.8.0 without Qt 5 support will be released earliest in autumn this year, then there should only be few people complaining, if they use some distro from the Debian family.

The first thing I would recommend to those users is the Flatpak. By using this, people not only can run OpenBoard, but they can also benefit from the improvements coming with current versions of Qt 6.

So, I recommend not putting too much effort into supporting a dead horse.

[sebojolais]

I agree.

However I am on ubuntu 22.04 and I do not like flatpak.
So I will create a branch on my fork to follow the dev branch and to continue with Qt5.
I will do that for sometime until I switch my OS to one more modern.

But do not interpret wrong my message, I think the switching to Qt6 is a good decision. 👍