Closed theodox closed 7 years ago
Makes sense to me Looks like QtPy doesn't support PySide2 yet, but they are working on it. Qt.py does support PySide2 though.
Would we want to vendor a copy of the library somewhere in mGui.qt, or should we leave it as an outside install similar to pyyaml with menu_loader?
I'd like to keep the dependencies to a minimum, given how annoying maya python distribution is. It's actually part of the reason I was thinking of copying Yaml for the shelf loader...
Pip basically does that, they keep a _vendor package where they keep all third party dependencies. https://github.com/pypa/pip/tree/master/pip/_vendor
Also looking through both libraries, neither has a solution for shiboken(2) vs sip. Qt.py seems to ignore it altogether, and QTpy only has references to sip. And only for setting some API flags. So both are incomplete for our particular needs.
also, I'm not averse to redoing the QTextBox class a different way if that takes Shiboken out of the equation...
So I was taking a look at how pymel ends up handling this problem, as they seem to avoid any direct usage of Qt related elements as well.
They basically wrote a set of functions, one for each of the Qt-bindings, that you can hand a gui object to and get back the QWidget
. They then have some simple import checks to determine which binding you have available, and defer all calls to the appropriate function.
With something like that we could just do the following:
from mGui.core.controls import TextField
from mGui.qt._utils import get_qobject
class QTextField(TextField):
"""
A wrapper around the QTextEdit in a Maya TextField. The main difference is that it
can emit events on every text change
"""
def __init__(self, key=None, **kwargs):
super(QTextField, self).__init__(key, **kwargs)
self.textChanged.data['qWidget'] = get_qobject(self.widget)
I'm all in favor of minimizing external dependencies... watching the QT4/QT5 nonsense from afar has confirmed all my prejudices
So I've started fleshing out an initial implementation. I'll add a branch for it either tonight or tomorrow after some more testing.
Closing this now that there's a PR
If we're going to keep things like the
mGui.qt
going forward we'll need to transparently support post Maya 2017. I think QTpy is the likeliest way forward. Thoughts?