I'm currently working on adding PyQt6 support via https://github.com/schrodinger/pymol-open-source/tree/qt6, but we have a mix of users that still using both PyQt and PySide flavors (it seems we have committed to honor that), with more now expecting PyQt6 and PySide6 since Qt5 is EOL (PyQt4 support can be safely removed). I don't think there's any need to enforce just one, and we haven't experienced any slowness in development or maintenance with the parity logic is mostly kept within these files.

I'd been mostly curious for several months to instead use something like https://github.com/spyder-ide/qtpy so that we don't need to manually support all four.

@JarrettSJohnson
Hm... I'm not sure I fully understand the purpose of supporting multiple libraries. Can users add their own custom user interface elements?

It's probably more of they already have either one in their virtual environment (perhaps for other applications). And yes, we can have users create custom elements via plugins: https://pymolwiki.org/index.php/Plugins. But that has a greater effect on tkinter though.

@JarrettSJohnson
My thoughts:

1. When installing the project, users will need to manually install one of the two libraries (pyqt, pyside) or set the "no_glut" flag. For a Python application, it is necessary to specify a list of required libraries in order for the application to function correctly. it's better not to shift this responsibility onto the user
2. Users who already have PySide installed in their virtual environment will not notice any difference, as PyQt will be automatically installed as a transitive dependency (run pip install . and the app is ready to go). Therefore, there is no need to worry about this
3. Supporting two libraries requires more effort, as you need to study the documentation, keep both libraries up-to-date and ensure they are interchangeable with each other (as i can see in qtpy repo, it didn't go well for the latest versions). (pic.1)
   
4. The documentation for the plugin only mentions pyqt support for version 3 of the application.

Because of these reasons, I don't see the point in maintaining two libraries. So, maybe I could finish this PR so that you can try it out and see for yourself if it will affect the users. What do you think about that?

For a Python application

I don't see PyMOL as a typically Python application. It's ~85% written in C/C++ and has a python interface for scripting and GUI. In fact, we had/have several project derivatives based off of this repo where things like Python must be stripped.

see for yourself if it will affect the users. What do you think about that?

I personally know users that use one or the other so they'll definitely be affected by this (reasons that they can only use on or the other), and the minimal cost of supporting both PyQt and PySide have been far outweighed by its benefits. It's usually requested the other way around where projects will typically have users request for support for both (hence why QtPy exists in the first place--I use it in my hobby projects without issues). If it was something where maintenance was difficult for us, like doing checks across more than several files, then I'd probably agree. If I were to rank the dependency-mixing that sorta "get in my way" as a PyMOL developer, Qt stuff wouldn't be high on that list. Things like graphics refactor for supporting modern graphics APIs as an alternative to our current setup with OpenGL would be and has taken many hundreds of my development hours; whereas trying to support PyQt6 and PySide6 probably has boiled down to just a couple of hours. The "Why fix something that's not broken" quote sorta comes to mind.

Supporting two libraries requires more effort, as you need to study the documentation, keep both libraries up-to-date

Qt does a pretty good job in keeping its API stable, and it's not something we have fought too much against in the past, especially since PyQt and PySide6 share almost identically...They kinda have to since it's based off of the Qt C++ API.

only mentions pyqt support for version 3 of the application.

It's probably more accurate to say python bindings for Qt. I wrote that in the PyMOLWiki article more in the context of writing plugins versus tkinter. Writing plugins with PyQt will be pretty much the same as that for PySide6.

So, maybe I could finish this PR so that you can try it out and see for yourself if it will affect the users. What do you think about that?

I'd probably hold off on it, to be honest. We're migrating to support Qt6 for Incentive currently for PyMOL 3.1 anyway, and I'm unsure how it will yet affect this repo. I do appreciate the work that's put in with this and the Meson suggestion. I'm the kind of developer that wants to refactor and decrease dependencies any chance I get, but there's some context that has to be considered (and even things that I'm not familiar with but other devs might be). I'd probably suggest for the future that ideas, especially infrastructural ones, would be raised as an issue or contacting us before PRs are constructed.

Hello, I've been using Pymol with PyQt6 (python3.12) for some time (https://github.com/jrom99/pymol-open-source/tree/qt6), since it supports dark mode on linux by default.

I've added the required namespaces and fixed all dialogs that I used in the meantime. As far as I know, PyQt5 also supports those namespaces (except for some iteration methods that I've found and changed).

I'm not sure if I can just submit a PR, since I have made some unrelated changes (updates to .gif exports, fix the icon naming on GNOME and my XDG changes), but I think the current ones can be helpful to get a PyQt6 version available.

Hi @jrom99 , I still haven't merged in the https://github.com/schrodinger/pymol-open-source/tree/qt6 branch yet (which is stale--I have an updated local branch that I worked on--there's a few other things I need to check first). I will probably do so later tonight or tomorrow.

@JarrettSJohnson

only mentions pyqt support for version 3 of the application.

I mean that I haven't found any commitment to PySide support

I personally know users that use one or the other so they'll definitely be affected by this

I'm still confused. If there's an obligation to support PySide6, why is it possible to delete PyQt4/PyQt5 support? Someone could still use them