update for QT 5 ?

[threedslider]

Later if can i update to QT 5 for Natron for RB-2.3 branch ? Devernay, you think it is good to make it or it needs to keep QT 4 ?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[devernay]

It should keep Qt4 compatibility. There are three platforms, thousands of users... any major change like this must be heavily tested. In fact the RB-2.3 used to build with Qt5, so it's not very far away. Please keep Qt4 compatibility. Qt4 is bloody stable.

[threedslider]

Ok on my way and understood.

[Sunderland93]

Currently, I see only one reason to porting Natron to Qt5: Wayland. But it probably a lot of more work, then just building with Qt5. Also, Flatpak-version of Natron contains patched and optimized Qt4

[devernay]

Thank you @Sunderland93
For some reason, too many people seem to think that porting to Qt5 is a high priority.
"3D" stuff is not high priority either IMHO (Blender is much better in that respect).
Wannabee developpers should concentrate on fixing the bugs to make Natron the best 2D compositor.

[threedslider]

Actually Natron is best 2D compositor yes :) But a touch of 3D would be nice to make Natron as complete VFX compositor too and it attracts more user to use that for more sharing with knowledge.

What bugs you mention as above for 2D compositing? I would know if I can fixing this bug ?

[luzpaz]

problem with not porting to Qt5 is that package repositories are phasing out Qt4 dependent applications. Just a recent example: void-linux/void-packages#13281

[rodlie]

@yomgui1 did a Qt 5.12 port in his fork (https://github.com/yomgui1/Natron), I have not tested it or know if he is done.

Porting to Qt5 is not a high priority for me at the moment.

[devernay]

Natron binaries include Qt4, which we build ourselves using a full set of patches and a few enhancement (most notably in the thread pool). We also give the full scripts to build all Natron dependencies.

I don't think it's a good idea to distribute Natron as a standard distribution package (deb, rpm, etc.), because of its high number of dependencies, which sometimes are required to be the latest version of a given package (eg openimageio).

[luzpaz]

All the experimental (rolling release-esqe) repositories:
Debian Experimental, Mageia Cauldron, Fedora Rawhide, Arch AUR, OpenMandriva Cooker, OpenSUSE Tumbleweed, Ubuntu 'Proposed', Homebrew, Linuxbrew, Homebrew Cask etc... these are all potential testers of the software

[devernay]

Sure, but given the lack of resources, it's much more efficient to make binary releases that run everywhere

[eszlari]

Currently, I see only one reason to porting Natron to Qt5: Wayland.

...and proper HiDPI support.

[phryk]

I'd really like to see qt5 support as I'm on FreeBSD which phased out qt4 quite some time ago and for which there are no pre-built binaries.

To me, depending on a framework that hasn't seen support in almost 4 years just seems wrong and I reckon the longer you delay the move to a supported version of qt, the more painful the eventual migration will become – which is a real shame since natron looks like it might finally be the usable and featureful FOSS video editor I've been waiting for…

[devernay]

Please study carefully the issues before trying to give any lessons.

We've been supporting Qt5 for a long time (take a look at the code).

BUT Qt didn't support PySide (aka Qt for Python) until Qt 5.12. We're not responsible for that.

PySide, if you know Natron, is an essential component.

Qt 5.12 was released in December 2018.

[rodlie]

@phryk you can build qt4+pyside from the 2018Q4 branch in Ports.

• https://github.com/freebsd/freebsd-ports/tree/branches/2018Q4/devel/qt4
• https://github.com/freebsd/freebsd-ports/tree/branches/2018Q4/devel/shiboken
• https://github.com/freebsd/freebsd-ports/tree/branches/2018Q4/devel/pyside
• https://github.com/freebsd/freebsd-ports/tree/branches/2018Q4/graphics/natron

[Ichthyostega]

QT4 is being phased out all over the place in the OpenSource world. (e.g. Ubuntu/Focal)
For me as a packager (for Debian/Ubuntu) this means to rebuild and dozens and dozens of packages, just to sustain the status-quo.

Note, I understand very well your situation and the limited resources.
However, please consider that under many circumstances, just installing some unverifiable binary blob is not an option. Rather, you need proper packages for the OS. And, even more important, living within an isolated code island, it becomes increasingly difficult over time to get help and support in case of any problems.

This is not an attempt to lecture you, rather an reminder of urgency for this topic.

[Ichthyostega]

...should also mention that the Python2 / Python3 situation is a significant part of the problem. For quite some time, there was a prevalent sentiment among many developers that "Python3 is stillborn and won't happen". Now, after an extended transition period, the distributions pull the plug, and some corners of the old Python2 ecosystem are simply dropped. This especially hurts us here, due to Pyside and Shiboken

[devernay]

We're distributing binaries, so you don't really have to care about packaging.
Natron is working for now, and we're still fixing bugs. Moving to Qt5+"Qt for Python"/Pyside2 represents quite some work, and also a lot (I mean a LOT) of testing. If someone wants to do it, they're free to fork Natron, do it, and try to reach the stability of the Qt4 version. I just won't do it.

Python2 is working too. For chrissake, who uses external python packages inside Natron? Nobody. Python2 is just a scripting language for Natron. It could be Lua, or Tcl, or Python3, we don't need thousands of packages from the "ecosystem" to use python2 as a scripting language. Tcl is still being used, and the last stable release dates from 2012.

[rodlie]

I agree with Frédéric.

Qt5 will introduce more bugs, we have enough to fix already. The bulk of our users use the binaries we provide, you can also find Natron as flatpak and snap.

Outside of satisfying distro maintainers Qt5 will not improve anything in Natron (IMHO), we get (questionable) support for High DPI and some minor nice-to-have features. Also, Qt5 is more or less EOL if it's not forked by the community (see 5.15LTS vs. opensource), and Qt6 is now the "next big thing" (with no improvements compared to v5 regarding desktop/widgets features/support).

I do understand that we need to support Qt 5.12+ at some point, but not now.

And btw, Qt4 is still used in major industries/companies to this day and for many years to come.

[eszlari]

we get (questionable) support for High DPI

Why do you call it "questionable"?

[rodlie]

Because it does not always work properly.

[eszlari]

Because it does not always work properly.

And? Every software has bugs. It's certainly better than not providing HiDPI support at all. And AFAIK they fixed most bugs with 5.14.

[rodlie]

Just saying that the only advantage with Qt5+ from a users perspective is HiDPI, and in my opinion it's not that good (at least was not with .13), that's all ;) If .14 has fixed the issues great.

Anyway... If someone want's Qt 5.12+ support feel free to contribute, see https://github.com/yomgui1/Natron/tree/qt5-dev

[alexmyczko]

@rodlie what Python.h are you including? Fails for me: http://phd-sid.ethz.ch/debian/natron/qt5/natron_2.3.15-1_amd64.build

[rodlie]

You are using 2.3.15? Qt 5.12+ support has not been merged (I don't have time to look into Qt5 until next month).

[alexmyczko]

the one you linked one previous

[rodlie]

You are missing the submodules.

[alexmyczko]

care to give me a pointer what i'm missing next? http://phd-sid.ethz.ch/debian/natron/qt5/natron_2.3.16~b1-1_amd64.build

[rodlie]

You are still building against PySide/Qt4. You will need to define BUILD_FOR_PYSIDE2 according to Macros.h (https://github.com/yomgui1/Natron/blob/qt5-dev/Global/Macros.h#L40).

[ShalokShalom]

And btw, Qt4 is still used in major industries/companies to this day and for many years to come.

It is also unmaintained and a potential security risk.

[devernay]

There are probably way more bugs in the Natron code itself that would qualify as security risks than in the Qt4 code!

I would say Qt4 itself is pretty much bulletproof, as it was used in a lot more software than either Qt5 or Qt6.

Most security fixes to Qt5 that were present in Qt4 were also backported, and are part of the patches that are applied to Qt4 in the binaries we distribute, see https://github.com/NatronGitHub/Natron/tree/RB-2.3/tools/jenkins/include/patches/Qt

[rodlie]

I would say Qt4 itself is pretty much bulletproof, as it was used in a lot more software than either Qt5 or Qt6.

I agree.

It is also unmaintained and a potential security risk.

If there are any known security issues I will happily backport them if needed/wanted, just show me a CVE or similar.

[luzpaz]

FYI, Manjaro distro has dropped Qt4 support

[rodlie]

Surprised they didn't drop it earlier, bleeding edge/rolling release distros don't tend to keep stuff forever.

[ShalokShalom]

KaOS dropped it like 2 1/2 years ago, thats why I am asking. We will also drop Qt 5, once its depricated..

[rodlie]

Most users (should) use the binaries we maintain, so I don't see this as a critical feature. Third-parties don't seem to be able to package Natron properly anyway.

I'm currently busy with other (more important) features in Natron at the moment, so Qt5.12+ will have to wait (if I'm going to do the work). Experimental Qt5.12+ patches exists (yomgui1@67bfaa4), but they are for the master branch, and will need to be backported to RB-2 before any serious work can begin.

[Echolon]

I will close this in favor of #256