digitaldomain / QtPyConvert

An automatic Python Qt binding transpiler to the Qt.py abstraction layer.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Any Binding -> PySide2

mottosso opened this issue · comments

I had a thought about how to increase the use, adoption and value of QtPyConvert, which in turn can help improve contribution and increase the number of eyeballs on the project.

For background, I think conversion from one binding to another is an interesting concept to many people, VFX artists and app developer alike. But the fact that they get to the README of this project and read about how it takes their precious code and converts it to a third-party, relatively unknown library such as Qt.py I think can be a little discouraging. I think most people, especially those unfamiliar with Qt.py, would be able to appreciate it further had it converted to something more "official" and known, like PySide2.

PySide2 is a stone's throw from Qt.py, so once it's there it would be a matter of search-and-replace of a few keywords (in fact, just PySide2 -> Qt). That part is actually already built into Qt.py,

python -m Qt --convert my_pyside2_project.py

I think the end result could be:

  1. People who aren't interested in Qt.py could still be interested in QtPyConvert
  2. Both those who are and aren't would benefit from a conversion to a binding they could later Google about and find answers for and potentially have pre-existing knowledge about as they fix any kinks coming out of the conversion.
  3. Finally, as a third-step of the process, if they wanted cross-compatibility, they could convert to Qt.py

You could call it PySide2Convert. :)

Just a thought!

The only trouble is that in a few years when QT6/Pyside3 comes out, everything breaks again?

Let's hope it's more than "a few" years. 😉

I like the idea of making an optional "--output" binding param so you could output to PySide2 if you wanted, or PyQt5 for example.

Perhaps even defaulting to PySide2 instead of Qt.py...

Oh look, QT6 is coming out this year after 5.15 .... thoughts?

I think the same can apply. PySide3 is likely only a stone's throw from PySide2, so the upgrade path would be..

  1. PySide -> PySide2
  2. PySide2 -> PySide3

That way this and the other project, PySide3Convert could remain independent, whilst still providing a complete path for very old projects. And so the story goes for PySide4+.