Feedback needed on new UI - Layer Locking

[scottrenaud]

Hey folks

We’re looking for your feedback on our Layer Locking designs, check it out:

layer_locking_designs_mayausd_ext_compressed.mp4

• Do you have any questions or concerns?
• What do you like or dislike?
• What would you add, change, or remove?
• When you lock a layer would you expect it to lock its sublayers as well, or would you provide such an option in the menu instead?

Thanks!
Scott
[email protected]

[jcoelho88]

Hi @scottrenaud, I like what I'm seeing.

Making this easy for artist to control is a good thing in my book.

"When you lock a layer would you expect it to lock its sublayers as well, or would you provide such an option in the menu instead?"

I would not expect a layers sublayers to also be locked, each one can be distinct. An option in the menu to allow it would be appreciated.

Cheers,

Jason Coelho

[BigRoy]

"When you lock a layer would you expect it to lock its sublayers as well, or would you provide such an option in the menu instead?"

Wasn't too sure about that one - I mean, technically nothing is holding us from still setting the flags for all the layers of course.

[BigRoy]

It's looking pretty good!

I do wonder - if these are "session stored" locked states and are not stored in the USD files themselves. How does the 'load stage' browser define whether the file to be loaded would be locked or not? The demo video does seem to show that for a file that the user is about to load.

---

What happens if for whatever reason the layer is marked as no permission to edit and no permission to save but the USD API does see unsaved changes on a layer. Will Maya still prompt "Save the changes" on scene save - or just disregard them and maybe log a warning?

I also suppose - in the USD API - nothing is actually by design keeping from that layer being edited or not; right? So it'd be up to custom tooling to just respect that layer.PermissionToEdit() flag for example?

[scottrenaud]

Hey @BigRoy,

I do wonder - if these are "session stored" locked states and are not stored in the USD files themselves. How does the 'load stage' browser define whether the file to be loaded would be locked or not? The demo video does seem to show that for a file that the user is about to load.

Not sure if this answers your question, but currently in Maya if a file is locked you’ll actually see that little icon on the file (on Mac anyway), so we wouldn’t be changing this.
We haven’t ironed out the technical part of it yet so we need to dig into it, but the proposal would be to detect the file permissions and then automatically set PermissionToEdit and PermissionToSave as a result.
Your question had me thinking about the possible conflicts we can run into if we persist flags set by TDs vs flags set by detecting file permission. Maybe you want to have a layer locked by the pipeline despite the file being unlocked (and user having full write access to it), and we’d need to ensure we’re not overwriting the pipeline layer lock the next time you open Maya type of thing.
Any thoughts?

What happens if for whatever reason the layer is marked as no permission to edit and no permission to save but the USD API does see unsaved changes on a layer. Will Maya still prompt "Save the changes" on scene save - or just disregard them and maybe log a warning?

In order to not be destructive we would leave those edits as in a frozen state in the Maya session, until the layer gets unlocked.
When saving the USD files out, in the save modal we list which files will be saved (including those that have PermissionToSave==False), but now knowing this information upfront we could make it clear which layers will not be saved out and also display an error if they proceed. If saving without seeing the save modal then we also would disregard the edits and should show an error.

I also suppose - in the USD API - nothing is actually by design keeping from that layer being edited or not; right? So it'd be up to custom tooling to just respect that layer.PermissionToEdit() flag for example?

As we’re using the USD API to write to the layers it should respect the flags and prevent the edits from happening.
All we’re really doing with these flags is essentially visualizing them a bit better and letting the user set PermissionToEdit (if PermissionToSave==False)

Really great questions, thanks!

[daviddeacon]

If locking is saved to the USD file and based on file permissions, this will create the same state for all users. Ideally, the list of locked layers is stored inside the Maya scene and restored on loading.

For a shot workflow, we use a single shot.usda loaded into the Maya scene with different department layers loaded as sublayers. For example, an animator scene would be set up with all other department sublayers locked apart from the animation sublayer.

For handling locking layers that have currently been edited, a dialogue could warn the user. This allows them to confirm and save the edits or discard the edits and reload the layer from disc. So you can't get into a state where you have unsaved edits on a locked layer.

[BigRoy]

In order to not be destructive we would leave those edits as in a frozen state in the Maya session, until the layer gets unlocked.

That'd also be up to that 2 GB limit?

Your question had me thinking about the possible conflicts we can run into if we persist flags set by TDs vs flags set by detecting file permission. Maybe you want to have a layer locked by the pipeline despite the file being unlocked (and user having full write access to it), and we’d need to ensure we’re not overwriting the pipeline layer lock the next time you open Maya type of thing.

I'd say always use whatever state got 'saved' with the file, but if file permissions disallow saving to override it visually for the user but do not change whatever is persisted in the layer?

has_permission = layer.PermissionToEdit()
if has_permission and not get_file_permissions(layer):
    # No file permissions always forces it on the front-end for the user
    # to appear 'locked'. Potentially this would show a different tooltip
    # or icon color when it's locked due to file permissions?
    has_permission = False

For handling locking layers that have currently been edited, a dialogue could warn the user. This allows them to confirm and save the edits or discard the edits and reload the layer from disc. So you can't get into a state where you have unsaved edits on a locked layer.

Yup - potentially even providing some "move edits to another layer" kind of feature to maybe move opinions to another layer that does have permissions, even though that can complicated quickly. I have something like in the Prim Spec Editor in usd_qtpy though which could be a reference albeit it's rudimentary.

[scottrenaud]

Thanks guys!

That'd also be up to that 2 GB limit?

That's correct, at least until this limit per layer changes.

I'd say always use whatever state got 'saved' with the file, but if file permissions disallow saving to override it visually for the user but do not change whatever is persisted in the layer?

I'll bring this to our discussions!

For handling locking layers that have currently been edited, a dialogue could warn the user. This allows them to confirm and save the edits or discard the edits and reload the layer from disc. So you can't get into a state where you have unsaved edits on a locked layer.

When debating if we should let the artist lock a dirty layer or not, we thought that allowing them to do it would give them the ability to freeze/lock work in progress so they could work on other layers (ex: if they're in an multi-layer workflow and want to be sure the other layers don't get modified, similar to layers in Maya and other apps), and come back to either unlock to make further edits and/or bulk save everything out (locked or not) when they're done.

If we prompted/forced artists to save or revert their edits every time they lock a dirty layer;

• it could break up their artistic workflow by having to think of impact
• possibly limit the usability/strength of the layer editor (where you can separate where your edits go)
• and could get artists into situations where partial saves impacts downstream

Looking forward to hear what you guys think about this!

[BigRoy]

If we prompted/forced artists to save or revert their edits every time they lock a dirty layer;

it could break up their artistic workflow by having to think of impact

That's a really good point. I hadn't thought about the artist just temporarily locking a layer to ensure they're not doing crazy stuff for a brief moment. That's what I think you are referring to.

and could get artists into situations where partial saves impacts downstream

Yup - having the artist see something but that not propagating downstream without some very clear visual design or warning will make things quite confusing for artists. This can get tricky quickly - luckily we do have the benefit of having the save icon still there that can remain a visual cue that some bits are unsaved of course, but still - it's a good point to focus on in UX whether it's providing the preferred clarity for the artists.

[richardHaw]

this is sorely needed, when we were looking into this last year. the layer-locking gimmick is the solution we thought of, at that time, we are locking the usd files anyway so they cannot be overwritten, but that is more like a hack than was born out of a security mechanic rather than a real solution.