Today, I’ve succeed more.or.less to use shiboken2, and I’ve even get a build of Natron with Qt5.
But … it doesn’t run : qt5 is not able to find its xcb plugin.
I need to rebuild qt5 in static mode to see if it improves… wait&see
2 Likes
Ok, good progress since yesterday.
Finally I win the fight with shiboken2. Now Natron UI opens, but got a crash just after answered
the box here:
[EDIT]
just found how to solve the xcb loading error.
But next fail is bad:
X Error of failed request: GLXBadContext
Major opcode of failed request: 150 (GLX)
Minor opcode of failed request: 5 (X_GLXMakeCurrent)
Serial number of failed request: 4870
Current serial number in output stream: 4870
[EDIT2]
my gl context is destroyed and no context is created when a gl call is done. this causes the crash.
I don’t know yet why the gl context is not keep.
But globally the build sound good.
[EDIT3]
By forcing the GL context to never die, I’m able to play with Natron/Qt5 now 
7 Likes
Awesome
Unstable Software, Libraries,etc is different perspective. I’m excited only because someone has started updating QT.
We had Natron running with Qt5 a few years ago already, but it was during the first few versions of Qt5 that were very unstable.
DId you already build and successfully run a Qt4-based build? You will need that anyway, even if it’s just for debugging purposes: whenever you encounter an issue, you want to know if it is present when using Qt4
I don’t see the point in having a video.
There are two scripts in the sources:
- build-Linux-SDK.sh builds all the necessary dependencies
- launchBuildMain.sh launches a build and packages it with an installer
If you want to develop on Natron, you only need the SDK, and you need to set a few environment variables before launching natron
@devernay yes, I’ve also an «annoying» qt4 build 
For sure, it’s a early WIP. Tons of tests and debug needed.
1 Like
I’ve pushed my work on my own fork on github: GitHub - yomgui1/Natron: Open-source compositing software. Node-graph based. Similar in functionalities to Adobe After Effects and Nuke by The Foundry.
THIS IS ONLY FOR YOUR EYES
I mean…
- no documentation on what I’ve changed
- no documentation on how to build/use
- only build on my machine ™
- only for me ™
- only to store my work somewhere else than on my HD.
2 Likes
Hi @yomgui
Thank you for that work, but be careful to keep backward compatibility with Qt4 as far as possible (use #ifdefs), avoid useless changes (siuch as reindenting source or changing the file order in a Makefile), and break down all your changes as much as possible, so that they can be cherry-picked. This kind of commit can not be merged upstream:
Showing 349 changed files with 49,540 additions and 40,607 deletions .
All commits still have to be reviewed before integration, so try to make the reviewer’s work as easy as possible.
Ahhh I’ve forget DO NOT MERGE point at the end ! 
@devernay about Qt4/Qt5 compatibility: big warning!
Sure Qt API itself is «almost» compatible, but the issue is on PySide.
PySide2 typesystem files and generated code is not compatible at all.
I mean the wrappers generated by PySide v1 must be keep away of PySide2 ones.
And the overall code may requires some changes for both of them.
The current way to record this generated code in the GIT repository cannot work.
So forget to make the code compatible at this layer.
Sure, I’ve not tried too long if there is a way to do that. But it’s out of scope of what I can do in my spare time.
I know what you’re thinking and what you hope, but if the effort to keep this compatibility is too high, no one would participate on maintenance.
When I’ll do push request, be sure that I’ll keep them as atomic and clean as possible.
This branch is only for me.
[Edit1]
When writing this message I’ve think that using a separated branch for Qt4 and Qt5 is the best way.
Qt4 branch can continue in «maintenance» mode (with Qt5 patches backport when possible).
[Edit2]
@devernay I’m testing a Natron sources tree configuration to have a cohabitation of Qt4 and Qt5.
IMHO, it’s a bit ugly and force to build and maintain two projects. But we can have Qt4 and Qt5 in the same GIT branch in this way.
I’m going to make a build procedure, as I’m introduce docker in the build system (but I’m using jenkins scripts).
When it’s ready for review, a PR will be done.
2 Likes
What ? 
Why QT4 with QT5 ?
@razorsharp Not at runtime for sure.
I think @devernay want to maintain a Qt4 branch to see if a bug is introduced only by Qt5 and having a «production proof» Natron (whatever this really mean).
BTW, I’ve joined a discord channel if you want to exchange some ideas with me : https://discordapp.com/invite/TP9GT3e
The existing code was already compiling with Qt4 and Qt5, what’s the point in removing Qt4 support, when all releases were built and tested on Qt4? Did you even run the full set of unit tests on the Qt5 version?
I agree to have a different set of shiboken-generated files for Qt5 (in another directory rather than a separate branch), but all other source files should compile with Qt4 and Qt5. The difference is not enough to justify a separate branch for now.
And, most of all, what’s the point in focusing on the upgrade to Qt5, which will bring its lot of issues, rather than fixing the existing issues? What’s the added value for the customer? Is it more important to have a compositing version that uses the last version of Qt, or to have something that is production-ready?
1 Like
It might be part of attracting new developers. It’s not really a point in a projects favor if it is built using a UI toolkit that’s been unsupported for a while. On a more practical side many distros are pushing to drop (or already have) qt4 from their repos (I know you build it from scratch for your binary releases, but there are people that prefer source/distro-packaged releases). These are not points for dropping qt4, that’s a different discussion, but reasons why I believe it to be very valid to try and get a stable version of natron with qt5.
2 Likes
Blockquote
Is it more important to have a compositing version that uses the last version of Qt, or to have something that is production-ready?
lol, I’ve so much seen this argument during my work in industrial domain…
Easy, none of them: False dilemma - Wikipedia
First production-ready is not a “simple definition” that anyone are agree with its bound. This is a per-project and per-people definition. We need to stop to use it as excuse to anything.
About Qt4: do you think that using Qt4 is production aware if I need to say to any team that the software they use is deprecated by those who made it and no bug-fixes will be released anymore?
They will get a smile 
Sure they don’t care about Qt4 vs Qt5, they want a software that can be used everyday and works without knowing how to install it.
BUT…
To make this last sentence a reality, we (developers) need to have right tools.
This is our requirement. We don’t sell Qt (we even not sell anything in fact).
But we need something strong at development level, to make things strong at user level.
It’s a well known causal effects.
For the fun, this is a real story.
I’ve work for a customer last year (world big one in TV broadcasting domain) that has exactly followed the gimmick “no fancy dev tool, no upgrade, don’t touch working code, only customer requests matter”.
Today all the code is java 5, tons of deprecated libraries with known bugs, running on a custom and manually maintained gentoo.
After 10 years of existence they decided to change for an Ubuntu has the tech lead of the
project and developers were upset to maintain libraries in Gentoo.
But it was too late, most of senior dev and architect have leaved the project as they were upset to never follow the usual technology improvement (not the only one reason for sure, but all ones have given this one).
Consequences: only 1 senior SW remains on the project, nobody understand the code (+1M lines).
But customers are happy with the SW in fact! … except that now they will not get much support for it as the team is reduced to the strict minimum to live and improvements are made at high cost.
Only because managers don’t care about developers.
«Happy Developers Make Better Software»
«No Devs, No Software»
Sorry @devernay if you think I’m a bit harsh with you, nothing personal, but you need to understand that Natron is an opensource software that needs developers first or the project will die. No ones is going to help you in the FOSS world if the technology behind doesn’t appeal them.
You and Alexandre have made a fantastic job: give it now a good and long life.
PS: yes, I’ve run the tests… all goods excepts 3 ones due to non-built pluggins. As this first stage was only a proof of concept, I’m happy with that
2 Likes
And Now for Something Completely Different
As for me Qt5 migration is a reality and as I’ve made an effort to keep Qt4 code working
with Qt5 one, these are my goals for next weeks:
- Continue to add one by one 3rd party libraries into the new Docker based build system.
- Be able to build Natron (not plugins) with a CY2019 compliant SDK (build on CentOS 7) and check if it runs on recent platforms likes Fedora 29 or 30 and Ubuntu 18.04.
- Write a documentation on how to build Natron with the new Docker system.
- Start to add plugins to the build system.
Notice that with Docker the build system is now fully independent of the host build machine and where is located. Nothing to install manually: only few commands to copy/past into you terminal. Fully automatized.
[EDIT1]
Step 1 and 2 done (but tested only on a Fedora 29).
This is the patch on my qt5-dev branch here: PySide2/Qt5 support and new docker-based build system · yomgui1/Natron@b2e931d · GitHub
There are some quick instructions on how to build it into the commit msg.
If some people are courageous enough to try them and report me issues on the build system, thanks a lot on the help.
Please note this is done on my fork of the genuine repository.
@devernay for sure, this patch is not ready for an official PR: I need to separate Qt5 port from the new build system, as the second part absolutely not giving release build and not gives all features.
But you can keep an eye on it 
[Edit 2]
I’ve broken the Qt4 build in my previous commit.
This is a fix, comes with instruction to build Qt4 version also with Docker: Fix QT4 build and provides Docker Qt4 build instructions · yomgui1/Natron@18804bb · GitHub
Time for a game: spot the differences in image below. Which one is Qt4? Which one is Qt5?
4 Likes
Good to see your progress.
Here i’m not able to build ( due to lack of experience with docker).
Well in fact docker.com has all of them 
For CentOS Redirecting…
For Ubuntu : Redirecting…
For Fedora : Redirecting…
For Debian : Redirecting…
1 Like