You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing we've done in ChimeraX is standardize on using integers instead of enum values as they exist in PyQt6 which poses a challenge because we're still thinking about whether we want to use that or PySide6.
We have two utility functions, qt_enum_as_int and qt_int_as_enum, to help us achieve the flexibility we need. For other packages (PyQt5, pyside2, pyside6) that don't use enums, we test whether the input is a subclass of enum.Enum and return the input if it isn't.
Does that sound like something that would be useful in compat.py?
The text was updated successfully, but these errors were encountered:
Hi @zjp thanks for sharing! I would say it make sense to me to have some way to achieve compatibility between things. Just in case, what do you think @ccordoba12@CAM-Gerlach ?
Sounds good to me to have the conversion functions in the qtpy.compat module, though we could consider also shimming over the actual differences if that's not already done and its straightforward to do (by changes in QtPy rather than monkeypatching the original packages).
One thing we've done in ChimeraX is standardize on using integers instead of enum values as they exist in PyQt6 which poses a challenge because we're still thinking about whether we want to use that or PySide6.
We have two utility functions, qt_enum_as_int and qt_int_as_enum, to help us achieve the flexibility we need. For other packages (PyQt5, pyside2, pyside6) that don't use enums, we test whether the input is a subclass of
enum.Enum
and return the input if it isn't.Does that sound like something that would be useful in compat.py?
The text was updated successfully, but these errors were encountered: