Qt6 support

[YakoYakoYokuYoku]

Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:

• I've followed the contributing guidelines to the best of my understanding
• I've read and understood the contributing guidelines
• I've formatted my code according to Natron's code style
• I've searched the pull requests tracker to ensure that this PR is not a duplicate

PR Description

What type of PR is this? (Check one of the boxes below)

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change which does not add functionality nor fixes a bug but improves Natron in some way)
• Breaking change (fix or feature that would cause existing functionality to change)
• My change requires a change to the documentation
  • I have updated the documentation accordingly

What does this pull request do?

This adds support for building Natron with Qt6. Besides from compilation fixes this does a pair of things, removes Qt modules in includes and rewrites the Shiboken cleanup script in Python. This can contain breaking changes due to the update so report issues if you encounter them.

Show a few screenshots (if this is a visual change)

N/A.

Have you tested your changes (if applicable)? If so, how?

By building and running Natron.

Futher details of this pull request

It's been a while since I've commited here, I hope I'm not that rusty.

[devernay]

Hi, can you please resubmit this PR on RB-2.7? RB-2.6 is Qt5 (mainly maintained by @acolwell ), which still wasn't released, and I wouldn't want to break anything in it.
@acolwell will you be available to review this?

[YakoYakoYokuYoku]

Hi, can you please resubmit this PR on RB-2.7?

As you wish. I'm gonna push a new branch for it.

[acolwell]

Hi, can you please resubmit this PR on RB-2.7? RB-2.6 is Qt5 (mainly maintained by @acolwell ), which still wasn't released, and I wouldn't want to break anything in it. @acolwell will you be available to review this?

I don't have a lot of time to devote to Natron right now. My preference would be to do as many changes that apply to Qt5 and Qt6 on RB-2.6 and only do the breaking Qt6 changes on RB-2.7. For example, I'm pretty sure the include changes, the KeySequence changes, RegularExpression changes, Mutex changes, and a few others are Qt5 compatible. This would at least keep the 2 branches relatively similar and allow us to verify behavior with Qt5 before making the Qt6 leap. I'm pretty sure some changes could also be structured in such a way that would minimize the Qt6 #ifdefs to a small number of locations by using typedefs (e.g. typedef QEvent/QEnterEvent to NatronQEnterEvent and QMutex/QRecursiveMutex to NatronQRecursiveMutex temporarily until transition to Qt6 is complete).

Based on my attempt at moving to Qt6 a while ago, a lot of the risk of breaking stuff came from the switch to shiboken6. As far as I can tell there doesn't appear to be many tests that verify the Natron python API so I couldn't convince myself that the significant changes I had to make to get shiboken6 working were correct and didn't break the API. It would be nice if we could have some testing in place to verify that all the exposed APIs are visible in python and work as expected in Qt5 so that we can easily verify nothing breaks in the move to Qt6. It would also be nice to add tests as part of the QRegExp to QRegularExpression migration to make sure that behavior isn't changed. Both were on my todo list, but I just haven't had time to do it. I think both of these are necessary to confidently transition to Qt6.

I'm also a huge fan of doing these in smaller, focused, individual PRs so that it is easy to review and verify each step doesn't break anything. Grouping these into a single PR containing multiple different changes across A LOT of files is just too hard to review and ensure correctness. If others feel differently, that is fine and they should feel free to step forward to do the reviews.

[YakoYakoYokuYoku]

@acolwell, the Windows builds are failing due to the include dirs variables not being defined there, please check the CMake config files of MSYS2 (at <prefix>/lib/cmake) as they might not define the variables.

[acolwell]

@acolwell, the Windows builds are failing due to the include dirs variables not being defined there, please check the CMake config files of MSYS2 (at <prefix>/lib/cmake) as they might not define the variables.

The installer builds don't use cmake. They use qmake so any changes made to the cmake files need to have equivalent changes made the qmake .pro files. It's a little annoying I know, but it is legacy that I haven't had time to fix. I'm not able to look at this right now, but I'll try to take a look sometime today.

[YakoYakoYokuYoku]

I thought that the installer builds moved to CMake, I wasn't in the loop. Albeit, as support for QMake dwindles each and every release, perhaps it should be the time to do the move.

[acolwell]

I thought that the installer builds moved to CMake, I wasn't in the loop. Albeit, as support for QMake dwindles each and every release, perhaps it should be the time to do the move.

For as long as I have been involved, the Windows installer script has used QMake. I'd love to move away from it since I already do all my Natron dev work on Windows w/ CMake and then just do a final verify with an Qmake installer build. I just haven't had the time to do the necessary work to transition the installer build to cmake and verify it generates an equivalent binary.