Remove PyQt from cross3d or abstract Qt use so you can choose to use PyQt or PySide

[MHendricks]

Currently cross3d is dependent on PyQt4 which is not easily available in most DCCs. We need PyQt for our database api, so we end up compiling a compatible version for each DCC. PyQt seems like a unnecessary requirement, so I would like to remove it.

I'm not sure when I will have time to work on this, so I'm adding this issue with requirements for any merge requests anyone is able to make.

The merge request should conform to one of the following:

1. Remove PyQt entirely(Preferred). I think cross3d.dispatch is the only module that "needs" Qt for its signal system. To remove this we would need cross3d.dispatch to use some other system for signals. It could be as simple as dispatch stores a list of functions and when it needs to emit them it iterates over each of them and calls them individually(It should always call all registered functions even if one or more of them raises a exception. It should still raise each exception that is raised so it can be debugged). If I remember correctly, I'm already doing something like this so I can track if I should disconnect the signals.
2. If PyQt can not be removed entirely, the Qt system should be abstracted. The user can configure if they want to use PyQt or PySide. I am using environment variables for other config options in cross3d so that should be a good way to configure it. Make sure the abstraction can work with Qt5 as Maya and other programs are moving to it. It should auto detect between PyQt4 or PyQt5 and PySide and PySide2.

[ReneVolution]

Maybe https://github.com/mottosso/Qt.py is what you are looking for?

[MHendricks]

Yeah, someone showed me that module the other day. It seems like a good way to implement the second option. I know we are going to the PyQt4/PyQt5 feature when adopting Maya 2017 or 2018.
That being said, I still don't think that Qt is needed for this module other than being useful for callback signals.

[mikemalinowski]

I know this post is two years old - but PySignal might be an interesting alternative to qt if you're primarily utilising it for the signaling.

I notice you're using QTimers and QColors along with a couple of other types from qt which would need refactoring out though.

Out of interest, is this repo still being updated?

[MHendricks]

Internally we have continued to develop and improve the code used in this. Maya has been improved quite a bit and small improvements in the other DCC's. However at the moment our internal code has diverged quite a bit and will require re-integrating into the github repo. The plan is to eventually update github with all the changes and start using it as the main repo for cross3d, but need to find the time to do that.

We have already migrated our internal cross3d to use Qt.py which addresses the second option. I was considering using a import mechanism similar to QtSiteConfig in Qt.py to allow users to choose if they use Qt signals or implement their own mechanism. It would attempt to import cross3dConfig and use the methods defined in there to connect the signals, if that module is not importable it would use a default implementation. This could also be used to address some of the configuration options and allow customizing other parts of cross3d.

I was not aware of PySignal, but that seems interesting. I'm going to have to look into it. I had to create my own mechanism for keeping track of if any signals were currently connected so I could disable the DCC callbacks if they were not needed. While important, it always felt a bit hacky that I couldn't figure out how to do it directly in Qt.