Page MenuHome

UI: Remove "Unset" from buttons context menu
AcceptedPublic

Authored by Julian Eisel (Severin) on Wed, Aug 26, 10:16 PM.

Details

Reviewers
Brecht Van Lommel (brecht)
Group Reviewers
User Interface
Summary

Introduced in rB37b82a2d260.

From what I can tell, this is only needed for the keymap editor, which already
has a 'x' button for this next to the properties. So in the regular context
menus this is just confusing, and there's no need for it.

Diff Detail

Repository
rB Blender
Branch
master
Build Status
Buildable 9835
Build 9835: arc lint + arc unit

Event Timeline

Julian Eisel (Severin) requested review of this revision.Wed, Aug 26, 10:16 PM
Julian Eisel (Severin) created this revision.

For any add-ons that define properties (stored in ID-properties internally), this allows them to be unset so the default values are always used.

Currently this is shown for all RNA buttons which is not very useful, it would make more sense to show this only in the case when PROP_IDPROPERTY flag is set for the property.


We could still remove it, just noting there is a valid use-case.

Perhaps Reset to Default should also unset ID properties? Then we can remove Unset and keep the functionality.

If there are specific use cases where you want to reset to default but not unset, then we could do it only for ID properties. But I can't immediately think of important enough use cases.

Initially I checked unsetting for custom props created in the UI, which didn't even show the unset menu entry; and I tested it with operator props, but didn't notice a difference compared to resetting to default value.
Checking again, there is a way to see the difference for operator properties: Move the 3D cursor, add an object, using "Reset to Default Value" for the location sets it to [0,0,0], unsetting the value moves the object to the 3D cursor.
So there is some use for it, even outside Add-ons.

If the unset state is important for an Add-on, it could show an 'x' icon for unsetting, just like the keymap UI does. The operator is still there after all.


I don't mind too much what we do as long as we improve this. If there's no real need for the context menu option we should get rid of it, that's what I wanted to figure out here. If there are other reasonable use-cases, we can go for a less radical solution.

Grepping for is_property_set, in Python I almost exclusively see usages for internal logic, no user facing options. E.g. checks in invoke() methods, internal operators, operators that require a property to be set, etc. The exception being object-add utilities in object_utils.py and obviously the keymap properties (which have the 'x' icon anyway).

For the C code it's a bit harder to tell. But it seems the vast majority of cases is still for internal logic (no user facing options), options where "Reset to Default" would give the same end result, or where it's easy for the user to set the value to what it was in the 'unset' state (e.g. booleans, small enums).

So right now, my proposal would still be to entirely remove the option. Add-ons can expose the operator if needed. We can add back the menu entry for ID-properties only if there's a reasonable need (or merge it with "Reset to Default Value").

Where it matters is that if a property is not set and an add-on changes the default value, it will get the new default value. This is because ID properties are lazily created.

For the most part users will not notice this, and for e.g. Cycles we use versioning to make sure the properties behave just like other Blender properties.

Anyway, I'm also not aware of specific use cases where Unset is required, so I'm fine with removing it.

This revision is now accepted and ready to land.Thu, Aug 27, 1:11 PM