Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qt5/Qt6 upgrade considerations #231

Open
mara004 opened this issue Sep 14, 2021 · 9 comments
Open

Qt5/Qt6 upgrade considerations #231

mara004 opened this issue Sep 14, 2021 · 9 comments

Comments

@mara004
Copy link
Contributor

mara004 commented Sep 14, 2021

Qt4 is deprectaed since about 2015, so I think it would make sense to finally drop Qt4 support in NodeGraphQt and move from Qt.py to Qt5.py. Implicitly NodeGraphQt already requires Qt5 due to the use of QOpenGLWidget, which got introduced with Qt 5.4.

Qt6 is also available since some time, and it would be nice if NodeGraphQt were eventually usable with PySide6, but I don't think there is a Qt6.py wrapper yet (and I'm not sure whether there will be one).
When developing a new application, I expect most developers would like to work with Qt6 directly, so maybe we could also consider dropping the wrapper and only supporting PySide6? This would help upgrade NodeGraphQt faster, and probably the majority of developers will want to work with PySide only anyway, since it is officially supported by TQtC and available under a more liberal license.
Moreover, Qt.py is not very suitable for building liberal-licensed applications, since there seems to be no proper way to enfore the use of PySide only, at least I couldn't find anything (apart from environment variables which only offer control over the preferred Qt bindings order at runtime).

What are your thoughts?

@davidlatwe
Copy link
Contributor

Hi @mara004 :)

When developing a new application, I expect most developers would like to work with Qt6 directly, so maybe we could also consider dropping the wrapper and only supporting PySide6?

Ideally, yes. However I think we need to stick with the VFX industry standard (which can be referenced here) for the compatibility across many different software packages.

@mara004
Copy link
Contributor Author

mara004 commented Sep 16, 2021

The VFX reference platform is interesting.
I agree that supporting both PySide6 and PySide2 for some time would be an ideal solution, also since PySide6/Qt6 still lack some modules compared to Qt5 (see here).

@5yutan5
Copy link

5yutan5 commented Oct 13, 2021

How about using qtpy, which is used in spyder project, instead of Qt.py?
It is not possible to use PySide6 yet in qtpy, but the master branch seems to be working on supporting PySide6.

@IceflowRE
Copy link

Upgrading this project to PySide6 is straight forward, if you don't want the Qt wrapper.

@mrkrynmdsco
Copy link

Upgrading this project to PySide6 is straight forward, if you don't want the Qt wrapper.

if interested, you can check this out.
I used the version 0.2.0 mainline, with its clean structure I just replaced 'Qt' package import with 'PySide6' and did minor debugging (esp. to QtWidgets and QtGui changes in Qt6).

Notes:

  • Basic tests only using the 'basic_example.py' and without installing the package.
  • Renamed 'NodeGraphQt' to 'nodegraph'
  • To be used for personal projects and prototypes

@IceflowRE
Copy link

IceflowRE commented Mar 26, 2022

Upgrading this project to PySide6 is straight forward, if you don't want the Qt wrapper.

if interested, you can check this out. I used the version 0.2.0 mainline, with its clean structure I just replaced 'Qt' package import with 'PySide6' and did minor debugging (esp. to QtWidgets and QtGui changes in Qt6).

Notes:

* Basic tests only using the 'basic_example.py' and without installing the package.

* Renamed 'NodeGraphQt' to 'nodegraph'

* To be used for personal projects and prototypes

Nice thank you! I will take a look. Iam currently using this project and adapt it to a custom visual scripting library (which doesn't use Qt).

@mrkrynmdsco
Copy link

mrkrynmdsco commented Mar 29, 2022

Upgrading this project to PySide6 is straight forward, if you don't want the Qt wrapper.

if interested, you can check this out. I used the version 0.2.0 mainline, with its clean structure I just replaced 'Qt' package import with 'PySide6' and did minor debugging (esp. to QtWidgets and QtGui changes in Qt6).
Notes:

* Basic tests only using the 'basic_example.py' and without installing the package.

* Renamed 'NodeGraphQt' to 'nodegraph'

* To be used for personal projects and prototypes

Nice thank you! I will take a look. Iam currently using this project and adapt it to a custom visual scripting library (which doesn't use Qt).

Please note that PySide6 version being used is 6.2.3.
I experienced an issue with 6.2.4 when the 'graph.auto_layout_nodes' is called, the window just close down. Not sure what the problem is.

@jowr jowr mentioned this issue Apr 26, 2023
@rajkundu
Copy link

@jowr provided some awesome work on upgrading this project to qtpy/PyQt6/PySide6. I updated his branch with the changes made to this repo's main branch since his diverged; I merged them both in my fork.

If anyone is interested in using PyQt6/PySide6 with this project, my fork is up-to-date, at least as of Aug. 20, 2023. I will try to keep it synced regularly.

Personally, I needed (i.e., really wanted) PySide6 in my project because PySide2 has no binaries for Apple Silicon. I think this project should really consider upgrading to qtpy/PyQt6/PySide6.

@nmstoker
Copy link

Hi @mara004 :)

When developing a new application, I expect most developers would like to work with Qt6 directly, so maybe we could also consider dropping the wrapper and only supporting PySide6?

Ideally, yes. However I think we need to stick with the VFX industry standard (which can be referenced here) for the compatibility across many different software packages.

It appears that CY2024 was finalized in September and it adopted 6.5 as the version for Qt for Python.

With that in mind, how are things looking with regard to moving to support PySide6 now? 2024 is just under ten weeks away 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants