Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Ideas for migrating to Qt5 #152
This issue serves as a discussion and as a reference about migrating the Syncplay codebase to Qt5.
In my opinion, there are three alternatives at this moment:
All these strategies have pro and cons, I will try to list them hereafter, being as objective as possible. In the following, I did not include PyQt5 because its open-source license (GPL) is not compatible with the current license of Syncplay.
Defer the migration
Port the UI code to PySide2
Port the UI code to Qt.py
Note: Qt.py is a shim that allows to code the UI using a common syntax and supports all the major Qt bindings (PySide1, PySide2, PyQt4, and PyQt5).
Everyone is encouraged to comment this issue with their opinion and ideas about this migration.
Now my personal comment on this: I would recommend to move to Qt.py right after the release of v1.5.0-final. The codebase is ready at present in my fork and requires only testing. This porting will allow to continue the coding of Syncplay without worrying about Qt anymore. The day PySide2 becomes sufficiently ready or PySide1 breaks, changing the binding will be equivalent to flip a switch.
Qt.py is licensed under the MIT license, so it is even more permissive than PySide and PySide2.
If we want to go directly to PySide2, we need to find binaries for it. Currently, the PySide2 team does not provide binaries for any platform. Anaconda is providing some binaries (based on two months old code) here, but these are not usable in macOS bundles due to packaging issues with py2app and conda. In my pyside2 and qtpy-pyside2 branches, I am currently using a custom PySide2 wheel that I built a month ago on my 10.11.6 system. Once again, the absence of tagged versions means that these two Windows and macOS versions of PySide2 will (almost certainly) be different from each other.
@alby128: I've spoken with Uriziel and he's happy with the proposed solutions and your summaries of them, so I think we're just waiting for 1.5.0 to be released and for @daniel-123 to confirm he has no objections and then we can go ahead with your recommendation of Qt.py which also has the support of @soredake and myself.