GUI overhaul with QT 5.12

You don’t need to be able to code to run qmake. And why would you want to change thecUI? It looks like Nuke, it’s quiet comforting.

Qt4 is not maintained anymore, so we may get into issues at some time by keeping it, although it is quite stable. For example, every new version of macOS brings its incompatibilities, and the Qt4 code has to be patched again to compile (see macports-ports/Portfile at master · macports/macports-ports · GitHub).

If somebody want to add compatibility with “Qt for Python” (the official replacement for PySide), then I’ll gladly review the pull requests. I would prefer if we could keep the possibility to build with Qt4/PySide, though.
One other thing is that I don’t think the master branch is the good place to do that, because the RB-2.3 is much more stable (although it has a few bugs).
My advice would be to make a new minor version (RB-2.4?) that adds Qt5 compatibility.

2 Likes

@devernay
Any update ?

Sorry, no time (at all) to work on this. But it should not be to hard to make the Qt5 transition for someone who already got the code to compile with Qt4. The code was compiling with Qt5 1 year ago, so the changes would mainly be in the PySide stuff (now called “Qt for Python”).

And just to be clear, I’ll accept any PR (pull request) that improves Qt5 compatibility without breaking Qt4 compatibility

@devernay
Can you upload an video on how to build Natron locally on CentOS 7 from start to finish ?

I’m working on Qt5 (.12) migration.
What I can say now: « @?#! of shiboken2 »

more technical speeking: Shiboken2 is not compatible with Shiboken.
Ex, You can not do this:

#define defaultvalue 1
class X {
public:
int add(int x, int y=defaultvalue) {return x+y;}
};

The “defaultvalue” define is handle py shiboken2 as a constant of the class X and not as a define.
The generated wrapper tries to do that:

int cppArg0 = X::defaultvalue; // gives compilation error, as defaultvalue will be changed for a 1

1 Like

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 :partying_face:

7 Likes

Awesome

<geek_joke>
Awesome? No, it’s the i3
</geek_joke>

https://awesomewm.org/
https://i3wm.org/

1 Like

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 :slight_smile:

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 ! :sweat:

@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 ? :roll_eyes:
Why QT4 with QT5 ?