Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maya 2025 patches #12

Conversation

trevorvanhoof
Copy link

@trevorvanhoof trevorvanhoof commented Aug 5, 2024

Maya 2025 uses PySide6 and shiboken6, so I had to try/except the imports to make it work across Maya versions.

I moved all Qt imports into widgets/widgets_utils.py and then imported that instead so this workaround only needs to happen in 1 place.
Additionally, because PySide6 moved a lot of things around between namespaces (QUndoStack to QtGui instead of QtWidgets for example), I opted to remove the namespace prefix everywhere.

The alternative would have been to identify every moved class and (in widgets_utils) reassign them to their old namespace in the PySide6 branch: QtWidgets.QUndoStack = QtGui.QUndoStack
But that seemed like a never ending task, and since all of Qt's classes are prefixed with a capital Q I think it is guarded enough against naming conflicts.

Resolves #11

@theRussetPotato
Copy link
Owner

theRussetPotato commented Aug 10, 2024

Hi @trevorvanhoof, thanks so much for taking the time to get this working in Maya 2025. I've never been a big fan to import entire modules with * since I find it really hurts readability, so I might explore alternatives first. Regardless this PR will be a huge help 🙏. I'll move this onto a different branch so I'll happily approve it and push it through while I weigh my options.

@theRussetPotato theRussetPotato changed the base branch from master to maya-2025-compatible August 10, 2024 06:21
@theRussetPotato theRussetPotato merged commit d2a1bc8 into theRussetPotato:maya-2025-compatible Aug 10, 2024
6 checks passed
@trevorvanhoof
Copy link
Author

trevorvanhoof commented Aug 10, 2024

I understand the aversion to import *, and it is forbidden in most style guides and linters afaik.

The 2 main reasons against it that I am aware of may not apply though I would love to hear why (else) it may not be a good descision; for self improvement reasons at least.

1: naming conflicts
by importing all we publish every name in the module which may not only introduce conflicts today; but it may introduce conflicts when updating qt and new names get added
This to me seems safe-ish because if the capital Q prefix (and why I don't do this for shiboken)

2: Import time code evaluation can be unexpectedly slow
Because PySide is a thin wrapper of a cpp library importing all is not going to execute much code so it is fast enough to just go for it (imo)

A middleground optiom I would be happy to put another PR in for is: import * in a qt.py file for ease of use (like I do now), and then import qt and prefix everything like 'qt.QPushButton' to have at least some namespace in the whole codebase to protect against conflicts

@theRussetPotato would that work?

@theRussetPotato
Copy link
Owner

theRussetPotato commented Aug 11, 2024

@trevorvanhoof
Points 1 and 2 are good reasons to avoid it, though I mostly agree these shouldn't (hopefully) be big issues here.
What irks me more is that it tarnishes readability - objects are being created but it's not clear where they come from. Instead of being something that can be identifiable at a glance, you have to actually dive in to see its source.

I can understand the reasoning though, so maybe it makes sense in this case, or maybe not. Thus why I wouldn't mind seeing if there's something else to make it more explicit. Hope that makes sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update for maya 2025?
2 participants