Merged
Conversation
Still not 100% though
But seriously though, these can't install pip anymore since PyPI is demanding the world stops using Python 2.7 immediately. No matter the consequences of maintaining legacy software. And they know best.
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a big one. With undo/redo that actually works reliably, and that includes tests for the most common edge-cases.
SAFE_MODE2.0onDestroyedandonRemovedcallbacks. They were unused and unsafe.node["attr"] = valueduring modifier-use, unused and not practicalDagModifier.lockAttr()and.niceName()andkeyableAttrfor better integration with undoUndo/Redo
In the previous version, and every version since then, cmdx has had a checkered past with undo/redo. It's a hard problem, especially when tackled outside of the intended
MPxCommandenvironment for which the API was designed.But it's done. It's safe, and it's fast.
Changed
~destructionof nodes, both native and custom onesmaya.cmdsare now sandboxed appropriately, e.g.DagModifier.lockAttrExamples
SAFE_MODE
There's always been a
SAFE_MODEvariable for cmdx, to try and produce a version that could not possibly crash. Any experimental feature - such as Undo in the early days - was put behind this flag.This flag now makes this goal more true. It simply should not be able to crash when
SAFE_MODEis active. It will however run about 10x slower due to the amount of added checking of validity it ends up doing.Callbacks
There were two callbacks registered to cope with reusability of
MObjectinstances. We now check for validity viaMObjectHandleinstead which relieves the use of callbacks. (And won't slow down your scene over time the more nodes become known tocmdx, which is enough of a plus on its own)Modifiers
A little-known - as well as complex/obscure - feature of the
cmdx.MDagModifieris that you can use the same syntax for setting attributes from within a modifier context manager.In practice, this wasn't very smart. Consider this.
You'd expect
nodeBto get set using this modifier, so it can be undone, because it happens within the context manager. When in fact it won't, since it isn't actually created by this modifier. And so, to leverage this convenience, you'd have to mix the two.And then there really isn't much point in having the convenience. This has now been removed, you now use
mod.setAttrto set an attribute via the modifier, andnode[]to set it outside of it. Simple.Plug Reuse
MPluginstanced used to be reused whenever you re-accessed a plug. But it isn't safe.. we can't know when an attribute is part of a node that has been deleted, or if the attribute itself has been deleted. Not without calls toMObjectHandle.isAliveandMPlug.isNullwhich costs as much as just finding the attribute over again.DagModifier.lockAttr
The modifier is essential for encapsulating a set of commands into a single undo block. But some things just aren't possible using a modifier, like locking an attribute, changing its nice name or editing its keyable state. These were tacked onto the cmdx modifier but aren't safe.. Locking of a dynamic attribute for example still can't happen via the API, and when we call
cmds.setAttrin the midst of a MDagModifier, we've entangled the commands for undo. What should it do? Undo the locking first, and the modifier later? What if the modifier created the attribute we're locking? Not safe.These have now been refactored to happen alongside a modifier and to play nice with undo.
maya.cmds, which also commits to undocmds.undoInfo(openChunk)And thus, they now play nice with undo.
The main limitation - aside from the performance penalty of translating a perfectly fine MObject into a full path and calling
maya.cmds- is thatcmds.addAttr(niceName=)only works on dynamic attributes. Bummer.