I’m a C++ developer in the VFX space and was looking to scratch some itches in Natron. I pulled the code and started looking to build it in my development environment (Linux, Python 3.8, Qt 5.15, PySide2) and noticed a few parts that look to be in a WIP kinda state.
I can see some attempts at Python3 compatibility, but I don’t know if those code paths have ever been exercised as they don’t currently compile (missing semicolons, use of removed Python2 functions, etc).
I’m a little more comfortable in a CMake build system, so I had a quick stab at writing modern CMake wrappers for the library and also noticed that the Shiboken bindings aren’t compatible with PySide2, so before I go much further porting and updating things I wanted to see if there was an overall plan for the codebase or if I was treading on any toes.
We only support Qt4 and Python2+PySide1. There are third-party experimental patches for Qt 5.12+ and “Qt for Python” (aka PySide2) support, but they where done against the (unmaintained) master branch and has not been backported to the RB-2.X branch(es), don’t know when that will happen (I guess I’m the one that has to do it), there are more important things to do (from my POV).
Which branch constitutes the focus for development then? I saw that RB-2.3 is currently the “default” branch, but master seemed more likely to be the focus as it was 2730 commits ahead.
Is there a plan for when Natron will jump to Python3, Pyside2, and Qt5? At the moment I’ve tried to keep things building under both paths, but PySide2 will definitely shake things up as the shiboken xml format needs significant changes (or a parallel file).
I’m happy to plug away at those changes if there is a chance they would be merged upstream, but it would definitely be easier if there was already a decision to abandon the Python2/Pyside1 code in the master branch.
So, Qt5.12+ support is something I would like to add on top of my todo list this summer (usually the best time for me to work on Natron).
If possible I would like to coordinate with others, that way we don’t have a lot of wasted efforts.
If you (@Shootfast) has done (or planning to do) anything please let me know in this thread or on GitHib (I’m also @rodlie on GitHub), else I will probably start backporting the work done by @yomgui when my vacation starts (not sure when, probably the end of June).
@Shootfast I am working on the Qt5 port as well. I’ve made a shared repo for me and rodlie (forked from Natron) at https://github.com/Songtech-0912/Natron, and I’ll be happy to invite you there are well to work on the port, if you’re ok with that.
I really appreaciate you guys pushing the project! It’s fantastic
It’s just the impression that the same work is done multiple times by different people. To me as an user the state of developent is less about the qt version rather than fun stuff like/especially deep compositing. Maybe instead of all doing qt/interface work someone gives deep a little love? I think this would be more rewarding for everyone. If it’s not deep I’m pretty sure there is something else.
I don’t care about qt4 vs qt5 either, but it has to be done at some point. I will take a look sometime this summer if nobody else has done it (or started) by then. I have several things on my TODO I would rather do, mostly related to Natron, not plug-ins (I might improve some existing plug-ins, but not make any new for a while).
Ole’s proposal to focus on stabillising Natron seems right to me. Maybe we can help you to confirm some bugs for example. Or discuss here the prioritys
For new features, we’ve got many things that can be done by advanced users like reproducing or preferred nuke gizmos
New features are definitely a great addition, but my focus at the moment (seeing as I am not one of the core devs) is the user interface. Currently, my focus is on bringing Natron’s UI up to par with modern design standards, as there are definitely certain things that could be improved for a UI several years old. Rodlie has done great work in this regard (with some widgets already in code such as a new colorpicker).
A UI redesign is in the design mockup stage, and implementation should begin once the final details are ironed out. If you’re interested in design, feel free to help out. If not, then here’s a (super general) list of priorities in no particular order:
