Moving to Qt5 should not be an issue. I did the initial port to Qt 5.6 and also fixed pyside2/shiboken2 at the time to work on MINGW/MSVC and on Linux. Everything was working at that time (end of 2016).
We should move to Qt5 at least for Windows due to OpenGL issues (we should use ANGLE). Also, moving to Qt 5.12 will exclude many OSX versions, v5.6 will work on 10.7+.
@rodlie do you have a look to my modifications for Qt5.12? (links in this thread)
I want to make you aware that PySide2 for Qt5.6 was the last release with a custom C++ parser.
Since Qt5.7, they have switched to a Clang based parser.
This change is major: it’s not trivial to use the official Qt PySide2 now, the Clang parser has failed a lot with Natron sources, I’ve changed various points in Engine/Gui and xml files. It wasn’t so trivial and I there are differences in UI. But anyway, the first step is done now. The only issue is I’ve used master and I need to rebase my changes on a “more stable” branch (please take a look to my commit ID in my note, just before yours).
But now, you brings a better point: the support of Qt5.12 on all platforms. How much you want to be compatible with older ones?
I have not had the time to look at anything related to Qt 5.12 yet. Getting updated on anything related to the project first.
Qt 5.12 on OSX is in my opinion a no-go, 10.12 is the oldest supported. Linux/Windows is not an issue, but we can’t have different versions on different platforms.
On my side I try to find a good “startup” point. Seems that the 2.3.14 is quite stable (I use the released files). But when I build the 2.3 branch I see many issues in the code. Lot of crashes (and lot of triggered assert() in debug mode). As example, in Gui/AnimationModuleViewCurveWidget.cpp, there are lot of weakptr.lock() without result checking, causing NPA.
The 2.3.14 doesn’t have such code. But in same time, the new code may have some good ideas inside. So for me, without the history knowledge, it’s difficult to find a “good” point to start. I don’t want to spend time to fix “R&D” code, as you never know the original idea/concept/direction of its creator.
I don’t have any knowledge on the code base after 2.1.9.
I would suggest we delay the port to 5.12 and rather get it working on 5.6 as a middle ground.
This also give us/me time to find out what differs between RB-2.3 and master.
From my previous post: “when I build the 2.3 branch I see many issues in the code.”
For me the RB-2.3 branch is also not correct. It looks that many changes has been introduced since the tag 2.3.14 (as I’ve said in my previous post). I said again: Are you sure?
RB-2.3 should only get bugfixes, looking at the changes from 2.3.14 to RB-2.3 I see mostly bugfixes and noise from the build scripts etc (the build stuff should be moved back to natron-support or something else).
master is WIP and will probably always be that. The person that knows how master works will not return so it’s a dead-end IMHO. We should branch master as wip (or whatever) and branch RB-2.3 as master and just move on.
master has a lot of good stuff, but that should be cherry-picked.
@yomgui: Fork RB-2.3 and whatever happens I will get your changes merged back. Just don’t break Qt4+PySide 
rb-2.3 is the default branch, no need to rename it to master.
there are interesting things in the master branch that may be back-ported at some point. The big error that was made (not by me) on that branch was to rename almost all source files. This makes it very difficult to merge changes between the two branches, but still I did it for every single fix: everything from rb-2/rb-2.3 was ported to the master branch.
do not separate the sdk and the build system from the sources. It is very well like that, and took me a lot of time to repair. This is part of Natron, and was kept separate for totally different reasons (which were to keep the secret sauce of building and testing Natron). The ofx plugins were kept separate only because they can be used in other ofx hosts. The community pyplugs we kept separate because they are maintained separately. Everything else should be in the Natron repo (including the test suite, which should be integrated ultimately, after cleaning).
Before integrating any change that potentially introduces bugs, make sure that everything is tested, and make a new branch (rb-2.4) if these are big enough changes, such as bringing in fully tested qt5 support. Any other work can be done on a fork until it gets properly tested and validated. Every pull request to the base code should be tested and reviewed.
I didn’t mean we should rename the release branch, just that we used ‘master’ for general commits and then did PR’s against the release branch etc. People will automatically think that the ‘master’ branch is where everything is "happening ".
It’s just a bit confusing for new people I would guess.
Anyway, not important. People should use RB-2.3.
@rodlie what I’ve said on the RB-2.3 containing buggy code remains true before the force-push:
the RB-2.3 has moved (forced) from c07e094da to eafb0a0b5.
I hope it’s the last force push on this branch.
Yes, I noticed it myself just before the fix was added (I was working on a bug and was a bit confused when I ran the program).
Anyway, Frédéric fixed it.
I have forked the RB-2.3 branch again and everything is ok.
Much more stable now!
Hi folks, is QT5 targeting is still active? Would be a huge favor for integrating Blender sides with Natron with pyside2.
QT3D has now become much more richer as well. Which means lots of possibilities are stuck with Natron QT4.
Also, is Natron using python 2.7 still now? Python 3 has so much more cross compatibility in subprocess pipe.
I am prototyping some pipeline with Blender and Natron and seems Natron needs lib updates too much.
Kind of…
Moving to Qt 5.12 will require a lot of testing, and modification to the build process. My goal is to add(*) support for Qt 5.12 this year, but work etc comes first.
(*) We will not drop support for Qt4, but add additional support for Qt 5.12.
Nothing has changed regarding Qt/Python, we are still on Qt4/Python2. Feel free to rebuild Natron against Python3.
Hi, is their any fork to build and test QT5?
You can test : Commits · yomgui1/Natron · GitHub
But it’s not in sync with RB-2.3, so I don’t know the status. You only need commit https://github.com/yomgui1/Natron/commit/67bfaa449e96ae8708a5cd8265f01731fb876323 (minus the build stuff).
many thanks
Note that Qt5 support was recently added to the latest development branch of Natron (RB-2.5) and was a separate effort.
Binary releases of Natron 2.6 will be using Qt5