MAYA-121877 cancel edit on maya ref under an xform #2186
Conversation
When a Maya ref is under a xofrm and that xform is edited-as-maya, show the proper menu for the maya ref and handle the cancel-edit correctly. - Detect the Maya ref for the context menu using the USD_typeName. - Refactor the code that use the USD_typeName attribute in the prim update manager. - Use the new common code in merge-to-USD, edit-as-Maya, discard edits and orphaned edits.
| @@ -415,10 +415,45 @@ PullImportPaths pullImport( | |||
| return PullImportPaths(addedDagPaths, pulledUfePaths); | |||
| } | |||
|
|
|||
| //------------------------------------------------------------------------------ | |||
| // | |||
| UsdMayaPrimUpdaterRegistry::RegisterItem getUpdaterItem( | |||
There was a problem hiding this comment.
This is refactored code taken from pullCustomize so that discardEdits and others can use teh same logic to decide which prim updater to use.
| return UsdMayaPrimUpdaterRegistry::FindOrFallback( | ||
| TfToken(usdTypeNamePlug.asString().asChar())); | ||
|
|
||
| // The root of the pulled hierarchy is crucial for determining push |
There was a problem hiding this comment.
Do we need this? This would be masking the lack of USD_typeName information in the pulled Maya data. I think it's adding complexity to the design and making it harder to understand. I get that it makes it more "robust", but I would argue that we are compensating for incorrect use of the framework.
There was a problem hiding this comment.
I was just moving the existing code that already did this. It was taken from discardEdits. It could still be useful if an edit-as-maya aborted mid-way through before setting the USD_typeName or it the user or Maya edition somehow removed the attribute?
Otherwose, I don't mind removing this fallback.
There was a problem hiding this comment.
I don't think it's worth the extra complexity, let's get rid of it.
| //------------------------------------------------------------------------------ | ||
| // | ||
| // Perform the customization step of the pull (second step). | ||
| bool pullCustomize(const PullImportPaths& importedPaths, const UsdMayaPrimUpdaterContext& context) | ||
| bool pullCustomize( | ||
| const Ufe::Path& initialPulledPath, |
There was a problem hiding this comment.
If we get rid of the initial pulled path in getUpdaterItem() you wouldn't need to change this interface.
Don't try to patch-up problems, use the design.
pierrebai-adsk
added
the
ready-for-merge
ppt-adsk
added
core
ppt-adsk
deleted the
t_bailp/MAYA-121877/maya-ref-under-xform-cant-cancel
branch
When a Maya ref is under a xofrm and that xform is edited-as-maya, show the proper menu for the maya ref and handle the cancel-edit correctly.