Supporting Qt 6 - What's needed?

[berniev]

And if we support Qt5 and Qt6 then there will be even more #ifdef's

Allow me for a moment to focus on the "if " in that comment.

Remember we are making decisions on what will be in the future, not as things are right now.

Especially given that all the stuff being talked about here won't go truly live for quite a while, I suspect min six months is not unreasonable, what is it that demands continuing support for qt5? Sorry, I just don't know the answer. If it is truly necessary I understand (there is much I don't know), but ...

From what I'm seeing, therre is a LOT of specific (literal) shiboken2, pyside2, qt5 stuff in the codebase. I'm still finding them. There is even a bunch of pre qt5 stuff (even though 4 was killed off) through conditionals. Perhaps a lot of that is due to poor implementation (specificity). The effort to support 5 AND 6 simultaneously will, I suspect be huge and complicated, and take a long time to implement.

If 5 support is a 1, and 6 support is a 1, what is the cost of supporting both? I suspect more like 5. But this is just a suspicion.

What is the cost/benefit tradeoff of keeping Qt5 while supporting Qt6?

[wmayer]

Remember we are making decisions on what will be in the future, not as things are right now.

Then define future. In a few years we of course will only support Qt6 but in the meantime there are a lot of releases of various distributions that only provide Qt5.

When I look at the Ubuntu repository then 22.04 is the very first release that provides Qt6 packages and choosing this as the minimum supported release (and all other distributions accordingly) is simply not feasible.

The effort to support 5 AND 6 simultaneously will, I suspect be huge and complicated, and take a long time to implement.

No, I don't think so. I guess it's around the same amount of work we had to support Qt4 and Qt5. It was << 5% of Qt-related code that needed an #ifdef.

When I think back the move from Qt3 and Qt4 was huge and effectively it was not possible to support both versions at the same time. Due to the massive changes almost all Qt-related code had to be re-written.

[chennes]

and PySide6 does things like drop support for the Qt resource system entirely.

Is there a reason for it? And what about Qt itself? Or is it rather that the Qt tools can be directly used for Python code?

No, I think I'm wrong about this -- I thought I was looking at the page about PySide6, but can now only find reference to the issue in the PyQt6 documentation, so I probably made the mistake that adrianinsaval pointed out above.

[berniev]

I'm stumbling along into the great unknown which is cmake.

Qt suggest that to get Core5Compat you:

Code: Select all

    find_package(Qt6 REQUIRED COMPONENTS Core5Compat)
    target_link_libraries(==tba== PRIVATE Qt6::Core5Compat) # Qt suggested

The first line I get, and it works, but how does one get the second line to work? It's not one I see much in FC.

Help?!

[wmayer]

I would not even try to use the Core5Compat module. Have a look at the classes that it provides: https://doc.qt.io/qt-6/qtcore5compat-module.html

From this list we only use the two classes QTextCodec and QRegExp. It's better to directly port the corresponding code to Qt6. A replacement for QRegExp is the class QRegularExpression and already exists since Qt 5.0. According to some forums the equivalent class for QTextCodec in Qt6 is the class QStringConverter or its sub-classes.

Then there is this guide to replace deprecated classes and functions in Qt 5.15: https://doc.qt.io/qt-6/portingguide.html

[wmayer]

git commit f9f201373f

[chennes]

QRegExp is actually a little harder because even though QRegularExpression existed, they hadn’t updated all the class that use it. Maybe that wasn’t true in C++, but it has bitten me in Python a couple of times.

[berniev]

QRegExp is actually a little harder because even though QRegularExpression existed, they hadn’t updated all the class that use it. Maybe that wasn’t true in C++, but it has bitten me in Python a couple of times.

Could you expand (for the dummies like me) what this means and how it affects FC?

[chennes]

It means we can't just change every use of QRegExp to QRegularExpression (even though that class itself exists). In cases where we are using another Qt class that uses QRegularExpression (e.g. QRegularExpressionValidator) we first have to double-check to make sure PySide2 actually implemented that class in our oldest supported version.

[berniev]

It means we can't just change every use of QRegExp to QRegularExpression (even though that class itself exists). In cases where we are using another Qt class that uses QRegularExpression (e.g. QRegularExpressionValidator) we first have to double-check to make sure PySide2 actually implemented that class in our oldest supported version.

Gee, on that basis the Compat thing (if, and only if, it works as advertised here) is starting to like attractive as it would allow Qt6 build and sort out those fine details later.