Qt5 support

[Sunderland93]

Hello. Debian 10 and future releases of Ubuntu will drop Qt4 from archive, so Natron's GUI need to be ported to Qt5. It also dependency on PySide, which has no Qt5 support. Any plans to do that?

---

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

[devernay]

Natron can ship with Qt4, so this is not a real issue. So Natron will still run. Natron also runs on macOS 10.13, although Qt4 is not supported since OS X 10.7: http://doc.qt.io/archives/qt-4.8/supported-platforms.html <http://doc.qt.io/archives/qt-4.8/supported-platforms.html> Qt 5.6 supports PySide, not later versions. So anyway we will have to ship Qt with Natron, be it Qt4 or Qt5. Natron compiles with Qt5 already, I just haven't tested yet the pyside/shiboken stuff. See http://www.vfxplatform.com/ <http://www.vfxplatform.com/> for more details. Volunteers are welcome: if you think you can help, I can give you a script that builds qt5.6+pyside+shiboken

[Sunderland93]

Qt 5.6 supports PySide, not later versions

Later versions have PySide 2 module (Qt for Python) https://wiki.qt.io/Qt_for_Python_GettingStarted

Volunteers are welcome: if you think you can help, I can give you a script that builds qt5.6+pyside+shiboken

I'll try, but I don't know how better: port all PySide code to PySide 2, or port it to PyQt5? I think that bundling Qt with Natron source tarball is not good idea.

[devernay]

pyside2 for qt 5.9 is unstable, see fredrikaverpil/pyside2-wheels#55 <fredrikaverpil/pyside2-wheels#55> only pyside2 for 5.6 seems to be usable. at least that's what autodesk and friends think (at vfxplatform.com <http://vfxplatform.com/>)

[Sunderland93]

What about PyQt5?

[devernay]

PySide was chosen over PyQt for obvious license reasons and industry adoption (see vfxplatform again). PySide has a liberal licence (LGPL), PyQt is either commercial or GPLv3. Somebody could make a PyQt fork/branch, or (better) make it a compile option in the main source code. We would then have a GPL3 Natron with PyQt and a GPL2 version with PySide. So the core version should continue using PySide in my opinion.

[Sunderland93]

@devernay ok, I understood. So, I see two ways out of the situation: build Qt4 and all necessary dependency's on PPA, and make a Flatpak package (over which I have already started work). And then, when PySide 2 is matured - think about porting to it. Or as you say - make Natron compiling with PySide and PyQt.

[devernay]

I would vote for the flatpak option first

[devernay]

The Qt4 bundled with Natron has many patches, included an important one for Natron concerning the threadpool. I'll soon release the script and patches we use to build Natron and all of its dependencies.
flatpak seems to be the best option for distribution, since we have to bundle that custom Qt4 anyway.

[Sunderland93]

@devernay maybe put all dependencies in 3drparty/ directory in Natron's tree (as submodules)? It would seriously simplify building Flatpak

[ShalokShalom]

Pyside6 is ready now.
https://www.qt.io/blog/qt-for-python-6-released

[rodlie]

Qt 6 will probably not be usable until 6.2 at the earliest. Qt 5.15 is also now EOL (LTS is commercial-only). Qt 5.12 LTS should be our target (IMHO), since it's the last supported Qt 5 version.

[devernay]

Qt 5.12 LTS is EOL on Dec 5 2021, so I would call it not-so-long-term-support.
Qt 5.15 will probably continue as community-maintained, at least for major Linux distributions, and is thus probably a better option.

[rodlie]

Qt 5.12 LTS is EOL on Dec 5 2021, so I would call it not-so-long-term-support.

Well, that's because the 5.15 LTS was supposed to replace 5.12, but it's now behind a paywall.

RHEL/CentOS 7 and Ubuntu 20.04 LTS both uses 5.12. So it will be supported until 2025.

5.15 was also a bit buggy on release (for desktop), not sure they fixed everything before going "offline". Anyway, not that important, we first need to support 5.12+ (and test), then worry about what to ship etc.

[ShalokShalom]

An AppImage is also a solution.

[rodlie]

An AppImage is also a solution.

Solution for what?

[ShalokShalom]

Bundle it without dedicated Qt4 support on the consumer devices.

[Songtech-0912]

Working on a Qt5 port at the moment. @rodlie Would you think it is a good idea to implement QtPy? Or should we just manually port the PyPlugs to support PySide2 instead?

[ShalokShalom]

Oh wow
QtPy looks amazing!

[devernay]

What do you mean by "implement QtPy"? You should already be able to install QtPy (and any other python package) using natron-python from the distribution. On macOS, it is simply:

/Applications/Natron.app/Contents/MacOS/natron-python -m pip install qtpy

[Songtech-0912]

To clarify, I didn't mean using Natron's embedded python to install QtPy via pip. My idea was that because QtPy is a compatibility layer that supports both PySide and PySide2, we won't need to port all the PyPlugs once we move to Qt4/Python 3.

Sorry, I misunderstood. I was under the impression that the initGui.py and any python scripts that modify the GUI (such as pyplugs) only support PySide as they start with from PySide.QtGui import *. Thus, I thought that they would break if we change to PySide 2 as part of the Qt5 port (which is probably true). I had thought (incorrectly) that you could prevent PySide scripts from breaking when run under Qt5 if you added QtPy as a built-in module in Natron's python interpreter. I thought that QtPy would allow those scripts to keep working because you could bind them to Qt5.

I realize now that it's redundant, because once we finish the Qt5/PySide2 port, there would be no need to bind to PySide anymore. Maintaining a compatibility layer for Pyside and PySide 2 makes no sense if only PySide2 is used. Sorry for the confusion.

[devernay]

Yes we could install QtPy in the default Natron distribution, and use it in all newly created PyPlugs, so that the code would remain compatible with Qt5/PySide2. However, pyplugs and code created before that will need to be converted manually to use QtPy

[Songtech-0912]

Yeah, that is the obvious issue here and it seems to be a lot of work with little payoff (because we will still need manual conversion to use QtPy anyway, while porting the pyplugs from PySide + Python 2.7 to PySide2 + Python 3.9 is probably less work as there is the 2to3 python tool for that). So @devernay I think we should drop that from the table?

[YakoYakoYokuYoku]

Marking with normal priority and in-progress as I'm working on this.

[YakoYakoYokuYoku]

Now that we have #697, #698, #715, #716 and #764 merged in branch RB-2.5 I'm going to say to any one that wants to test this to go ahead, build Natron as #802 says (or INSTALL_LINUX.md when merged) and report how things went so far. In case you stumble upon a bug or you see that a previous problem is fixed with Natron Qt5 then don't forget to check out the issues page.

[marillat]

natron build still ask for pyside when only pyside2 is available.

Package pyside was not found in the pkg-config search path.
Perhaps you should add the directory containing `pyside.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pyside' found
Package pyside was not found in the pkg-config search path.
Perhaps you should add the directory containing `pyside.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pyside' found
Project ERROR: pyside development package not found

[YakoYakoYokuYoku]

natron build still ask for pyside when only pyside2 is available.

That's due to the absense of python3 in the CONFIG variable, at the moment you can fix this by adding CONFIG+=python3 to the qmake command

$ # basic example though you should the command arguments you were previously using
$ cd build
$ qmake -r ../Project.pro CONFIG+=python3

When #803 is merged then QMake will add python3 to CONFIG by default in a Qt5 build.

[marillat]

Still the same
Environment Debian amd64 unstable

Package pyside was not found in the pkg-config search path.
Perhaps you should add the directory containing `pyside.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pyside' found
Package pyside was not found in the pkg-config search path.
Perhaps you should add the directory containing `pyside.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pyside' found
Project ERROR: pyside development package not found

[YakoYakoYokuYoku]

So strange, mind if you could share which branch you are using and your qmake invocation command?

[marillat]

$ LANG=C git branch 
* (HEAD detached at origin/RB-2.5)

qmake -r CONFIG+=python3 PREFIX=/usr

[YakoYakoYokuYoku]

Three more questions, are you using a config.pri, is it your clone up to date and is your qmake using version 5.15?

[marillat]

confi.pri is untouched from git.
git is up to date and qmake is 5.15.2

$ qmake -v
QMake version 3.1
Using Qt version 5.15.2 in /usr/lib/x86_64-linux-gnu

As I did Natron Qt4 Debian package before I try to never modify source code.

[YakoYakoYokuYoku]

I think the problem is in config.pri, as that might be what's pointing to pyside instead of pyside2, either ways you should modify it or remove it (no problem with that as it's ignored by .gitignore).

[marillat]

config.pri must not be deleted

qmake -r CONFIG+=python3
Cannot read /home/marillat/Natron/config.pri: No such file or directory
Project ERROR: System-specific config.pri file not present, please follow the installation instructions and create it.

and pyside is also defined in Engine/Engine.pro

Reading /home/marillat/Natron/Engine/Engine.pro
Project ERROR: pyside2 development package not found

[YakoYakoYokuYoku]

Uhh, global.pri is not taking config.pri optionally, I think that if you use an empty file it'll suffice, though can I ask for its previous contents?

[marillat]

Well now I'm able to build Natron with one exception I need to add boost: LIBS += -lboost_serialization in config.pri

/usr/bin/ld: /home/marillat/Natron/Renderer/../Engine//libEngine.a(AppManagerPrivate.o): in function `boost::archive::detail::common_oarchive<boost::archive::binary_oarchive>::~common_oarchive()':
AppManagerPrivate.cpp:(.text._ZN5boost7archive6detail15common_oarchiveINS0_15binary_oarchiveEED2Ev[_ZN5boost7archive6detail15common_oarchiveINS0_15binary_oarchiveEED5Ev]+0xf): undefined reference to `boost::archive::detail::basic_oarchive::~basic_oarchive()'

[marillat]

Now I have a Natron package I'm trying to use it.
If I remember correctly Natron can't start without al least openfx-io plugins installed. Right ?

[YakoYakoYokuYoku]

You can start Natron without them, though you're not going to have access to image or video I/O. From now on if you encounter individual bugs with Natron Qt5 I'd encourage you to check the issues tab or open a new one.

[marillat]

Done in #808

[devernay]

closing this issue, continued in #827