Qt.py (Maya 2017, PySide2)
Fredrik Averpil
Hello,
Today, Maya 2017 was released. It comes with a bunch of changes, where one change is of particular interest to me as a Python developer; PySide has been replaced with PySide2 (as a result of Autodesk replacing Qt4 with Qt5).
This essentially makes all PySide/PyQt scripts written for Maya version <= 2016 unusable in Maya 2017.
To help fix this, and maintain backwards compatibility to previous versions of Maya, Marcus Ottosson and I created an open source project called Qt.py:
https://github.com/mottosso/Qt.py
By writing as if you were writing for PySide2, and using our shim instead of a specific Python binding, this simple example code works in Python 2 & 3 with either PySide, PyQt4, PySide2 or PyQt5:
import sys
from Qt import QtWidgets
app = QtWidgets.QApplication(sys.argv)
button = QtWidgets.QPushButton("Hello World")
button.show()
app.exec_()
If you’re in the same boat as us, we’d love to hear what you think about this.
To help get you started, here are two blog posts which outline how to use Qt.py:
Regards,
Fredrik
Cesar Saez
So you have to write for qt5 bindings in order to fallback to older bindings?
How does this help to limit refactoring on old scripts? (i.e. using the new QtWidgets instead of patching QtGui).
Don't get me wrong, I have done and worked with similar solutions on different studios and I fully appreciate what they bring to the table (especially for in-house software where portability is not a big issue), but the way the project is presented is a bit miss-leading imho (and the default a bit odd).
Marcus Ottosson
Sorry for any confusion.
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPamJi-LAOkz-0_MadX%3D6-kxrzmrXYUW7Qfj222a%3DRMEa6k%2BYw%40mail.gmail.com.
--
Fredrik Averpil
So you have to write for qt5 bindings in order to fallback to older bindings?
How does this help to limit refactoring on old scripts? (i.e. using the new QtWidgets instead of patching QtGui).
I’m sorry if you thought Qt.py would help you convert your old scripts into working with Python bindings for Qt5. Like Marcus said, you’d still have to write your scripts as if writing PySide2 code. Then it will offer a degree of binding agnosticism as well as a backwards compatibility to Qt4 bindings.
I’ve heard good things about this conversion script which might help you with the conversion from PyQt4 to PyQt5: https://github.com/rferrazz/pyqt4topyqt5
I’ll only speak for myself, but in our studio, we’re now using PySide, PySide2 and PyQt5. We’re also using a mix of Python 2 and Python 3. I also write a lot of scripts which are intended to run in all those Python environments. For us, Qt.py really is a lifesaver.
Don’t get me wrong, I have done and worked with similar solutions on different studios and I fully appreciate what they bring to the table (especially for in-house software where portability is not a big issue), but the way the project is presented is a bit miss-leading imho (and the default a bit odd).
I would really wish to understand which part you felt was misleading so I can fix that. Was it my email, the blog posts or the Github repository?
How do you mean that the default is a bit odd?
We thought it would be a good idea to move forward with Qt5 and not get stuck, but offer a way to make those “new” scripts to actually run where only Qt4 bindings were available.
Regards,
Fredrik
Cesar Saez
> This essentially makes all PySide/PyQt scripts written for Maya version <= 2016 unusable in Maya 2017.
Fredrik Averpil
I guess my confusion comes from reading this paragraphs, but it’s all clear now.
This essentially makes all PySide/PyQt scripts written for Maya version <= 2016 unusable in Maya 2017.
To help fix this, and maintain backwards compatibility to previous versions of Maya, Marcus Ottosson and I created an open source project called Qt.py…
Ah, I agree. I now see I should have chosen my words more carefully. :)
On the defaults I guess it depends on your goal/scope, what you describe makes perfect sense for distribution of new software that have to run within different environments (i.e. pyblish), but if you have an existing large codebase in your studio maybe it’s more convenient to patch the new qtgui including the widgets at runtime (or account for this reality in some way).
Yes. I think there could be different approaches when talking about old code vs new code. Personally, I’ve opted for Qt.py for the old code too, to keep things consistent here. It’s just one choice of many.
For the record, we have a similar python package extending and giving access to qt bindings at work and the migration wasn’t a big deal, there’s always some small percentage of ‘TD code’ around not following standards (therefore broken), but having control over the way tools/frameworks have access to the bindings is very important and I totally recommend it.
Yes, agreed.
I was first shocked when I learned about PySide/PyQt4 being left out of applications moving onto Qt5… oh my god, all that code!
But when I learned what it really meant to tweak your code for PySide2 or PyQt5, I was revealed it wasn’t that big of a change. At least for us it wasn’t since it mostly came down to widgets and styling. But then a new shock set in when I heard PySide2 will not be developed for Python 2… and so it goes on…
But so now I’m happy writing code using our Qt.py shim, especially in those cases where I know the script/app will run in many different Python environments.
// Fredrik
zoshua
Marcus Ottosson
--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/4c5c0954-41ee-47b4-973a-ad6971e4ec5e%40googlegroups.com.