Switch to Qt6

[XVilka]

No description provided.

[karliss]

Current progress:

• cutter-deps-qt , cutter-deps and cutter compile, now dealing with details

TODO:

• cutter-deps-qt
  • Linux
  • Windows
  • macos
    • x86_64
    • arm
  • Cleanup
  • merged
• cutter-deps
  • Linux
  • Windows
  • macos
    • x86_64
    • arm
  • merged
• decide what to with GCC binaries and libstdc++
• rebuild Linux cutter-deps (pyside for some reason didn't include bindings for parts of Qt)
• yara plugin qt6 patch
• cutter fully compiles
• test that the builds work (including python plugins)
  • Windows
  • Linux
    • wayland packing
    • Arch
    • Ubuntu 18.04 (qt5) -
    • Ubuntu 20.04
    • Ubuntu 22.04 (libfuse2 not installed by default, problem for Appimage in general)
    • Ubuntu 24.04 (mostly ok, in some of the first runs main window didn't open properly, but afterwards the problem disappeared,)
  • macOS
• update example python plugin
• python plugin metadata QString/string problem
• cleanup
• 6.7.2 update

[karliss]

I had problems getting Pyside 6.5.3 to build in combination with Python 3.12.2 . During build process when it was running shiboken to generate qt bindings it crashed.
Looks like they had quite a bit of changes to ensure Pyhon 3.12 compatibility https://bugreports.qt.io/browse/PYSIDE-2230 , but those were supposed to be included in Pyside 6.5.2 already.

Using Python 3.11.9 build succeed. Will try out what happens with 3.12.1. From the note in Python 3.12 support issue it sounded like they expected a high chance of breaking in future python versions due to python adding more optimizations.

[karliss]

Pyside/Python compatibility table on https://wiki.qt.io/Qt_for_Python has a red cross for Python 3.12/Qt 6.5 .

Checked out the git repo for pyside. There were quite a bit Python 3.12 compatibility fixes comited both in 6.5 and other branches after 6.5.3 tag. Probably not worth trying 3.12.1 .

Will probably stick to 3.11 for now. 3.12 can be reevaluated once we get 6.5.4 (assuming Qt won't limit to commercial customers).

[XVilka]

I think sticking on Python 3.11 is fine for now, since it will not EOL for quite some time:

Ends in 3 years and 6 months (31 Oct 2027)

https://endoflife.date/python

[karliss]

A bit more details on the two Appimage thing I suggested in mattermost.

QT6 requires C++17 which requires appropriately new GCC, which in turns means that whole thing will depend on new libstdc++.

While it is possible to build a new GCC for old Ubuntu that would still requires a new libstdc++ on target system to run the Cutter. And bundling libstdc++ is a bit problematic and strongly discouraged by Appimage devs. One problem with that is that even though Appimage bundles most libs, there are couple that will always be used from system. And if any of those use c++ then there are problems. If I am not mistaken one of the problematic ones are the GPU driver libs (and you definitely can't bundle the GPU driver libs). There are some solutions which bundle libstdc++ and choose whether to use bundled or system libstdc++, but they seemed somewhat messy and would mean introducing one more obscure dependency .

Static libstdc++ linking has it's own issues by itself, but in our case we have quite a few modules interacting with each other and in some cases having C++ on the module interface boundary Qt<->Cutter and Cutter<->Cutter plugins. So this option also doesn't seem great.

Overall it seems much cleaner to just build two Appimage builds

• one based on QT5 built on Ubuntu 18.04 for maximum compatibility
• second build using same QT6 version as macOS and windows build, built on Ubuntu20.04 for more up to date distros

Having the two Appimages is slightly against the ideology of Appimage, but that seems like least of evils among available choices.

Some other approaches I would prefer not doing:

• Making Linux release builds using QT5 while other desktop platforms are using QT6
• Dropping Qt5 support and raising the system requirements

It wouldn't hurt to also make a fresh version of QT5 cutter-deps (only for Linux) using the latest QT 5.15 bugfix release from KDE. But in the initial version it can use the cutter-deps we already have.

[XVilka]

Why not use more recent Ubuntu version as the base for Qt6 AppImage then? The latest LTS, for example. Since we provide two images, it should not hurt to use more updated dependencies as well.

[karliss]

Why not use more recent Ubuntu version as the base for Qt6 AppImage then? The latest LTS, for example. Since we provide two images, it should not hurt to use more updated dependencies as well.

The obvious reason is because it would narrow down the window of systems compatible with the QT6 build which. I expect having QT6 on more systems to be more beneficial than low level libs on which the QT depends as those are more likely to be relatively stable. Also 20.04 is still within standard support window.

If the concern is about getting every lib with latest patches as much as possible Appimage isn't exactly the best approach anyway, for that having a system native package or even flatpak would probably be better and more frequently updated. Not like we are regularly rebuilding cutter-deps.

Although if anyone has good specific example of having cutter-deps (or final cutter) built against newer system libs improves the resulting user experience I am willing to reconsider this.

I wonder how wayland optional protocol negotiation works (and QT handles it). Since single system can have multiple desktop environments each supporting different subset of wayland optional protocols, I assume it's at least somewhat dynamic. Would all the optional protocols supported by Qt work, assuming the system running Appimage also supports them, or is there anything that Qt disables at build time.

Otherwise things are slowly but steadily moving forward. Just got the cutter-deps building on windows, now need to fix anything I broke in macOS/Linux builds while attempting to get the windows building. Afterwards will be able to move on to ensuring Cutter works fine with the new cutter-deps.

[XVilka]

Pyside/Python compatibility table on https://wiki.qt.io/Qt_for_Python has a red cross for Python 3.12/Qt 6.5 .

Checked out the git repo for pyside. There were quite a bit Python 3.12 compatibility fixes comited both in 6.5 and other branches after 6.5.3 tag. Probably not worth trying 3.12.1 .

Will probably stick to 3.11 for now. 3.12 can be reevaluated once we get 6.5.4 (assuming Qt won't limit to commercial customers).

Should be fixed in Qt 6.6 and 6.7. Qt 6.7.1 release is planned this week: https://wiki.qt.io/Qt_6.7_Release
There are few interesting changes for us in the 6.7: https://doc-snapshots.qt.io/qt6-6.7/whatsnew67.html#platform-changes

[karliss]

I saw in the compatibility table that Python 3.12 is supposed to work with Qt6.6+, but wanted to stick to QT LTS. Now that I checked their release history again seems like last open source Qt 6.5 release is whatever was released before 6.6 release. I remembered that they switched to LTS being mostly for commercial customers, but I hoped that there would be something. I guess I remembered wrong, and there is absolutely no reason on using 6.5 at this point.

Will update the build scripts to 6.7. Shouldn't be much work compared to the 5.15->6.5.

There are few interesting changes for us in the 6.7

@XVilka What seemed interesting to you? I read it, but didn't notice anything important. Most of the feature additions and API improvments don't affect use since we are keeping compatibility with older Qt versions. I guess better Windows11 theme support is nice to have.

[karliss]

Got Qt 6.7.1 compiling now started working on Cutter CI part.

[XVilka]

Most of the feature additions and API improvments don't affect use since we are keeping compatibility with older Qt versions. I guess better Windows11 theme support is nice to have.

Yep, it's about better Windows 11 and macOS 14 support.

[karliss]

One more small problem I noticed while testing this.
With the newer Pyside/Qt it complains about plugin metadata being string not QString. Something like:

sys:1: RuntimeWarning: Invalid return value for plugin metadata name, expected QString, got str.

For all 4 fields

class CutterSamplePlugin(cutter.CutterPlugin):
    name = "Sample Plugin"
    description = "A sample plugin written in python."
    version = "1.2"
    author = "Cutter developers"

It's probably possbile to prevent the error by manually creating QStrings in python, but it would be nice to fix it in the bindings.xml.in/plugin_meta_get function so that it works just like before .