That the problem: the build has not “failed”, it has just stuck. Not responding. How to have the log if only CTLR-C the docker image build is possible?
I’ve found what I’m talking about: http://libregraphicsworld.org/blog/entry/the-demise-of-natron
The «master» indication is here, there is no mention that the 3.0 version was left «broken» by Alexandre, only «not finished». It’s confusing.
I going to swap on your 2.3 branch and cherry-pick my patches on it.
Well, it’s not finished, full and bugs, and mostly undocumented. It doesn’t even pass the unit tests as far as I remember. Did you even try running it and using is to do a real compositing project? I probably was the only serious user for this version, and believe me it’s a pain in the ass.
Note that every single patch I do in the RB-2.3 branch is also applied to master, even though it is sometimes a lot of work (because filenames were changed and files were split)
@devernay: from what I’ve tested until now on the master branch, most of crashes are 0 division inside the ffmpeg reader when I reach the end of file.
The Natron SDK docker image is now available from Docker Hub
For now it is Qt4 only, but it should be fairly easy to update the Qt5 section in the SDK build to build Qt 5.12 with Qt for Python.
1 Like
@devernay in latest GIT, the command “git diff --stat origin/RB-2.3 origin/master” returns only doc and tools changes, nothing on code. You’ve said that master is full of bug and RB-2.3 branch should be used, but except for sdk, it’s the same code…
Have I missed something?
there was a wrong merge: Merge branch 'master' of https://github.com/NatronGitHub/Natron into … · NatronGitHub/Natron@f1c25cc · GitHub
I will revert it, but in the mean time you can use MacPorts: update (first batch) · NatronGitHub/Natron@9542ac6 · GitHub
RB-2.3 is fixed, but you will have to clone it again
@devernay hmm I think it’s wrong again: if I carefully follow branch merge since the 2.3.14 tag, the last one valid before merging all buggy changes is 7633b0dad3c85e617b6e856002ebabaddf714e80
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.
1 Like
@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.
1 Like