Page MenuHome

Menus & Context Menus: What to do if operators aren't valid
Confirmed, NormalPublicDESIGN


This is a design doc to clarify how we should handle cases where operators aren't applicable.

Currently, we deal with this poorly:

  • In the context menus, we often show properties that won't work (such as when nothing is selected)
  • In regular menus, sometimes operators don't work in certain criteria, but it isn't communicated

Here's how I think we should solve it:

Context menus

Rule: Only ever show operators here that actually work in the current context.
This means that, if nothing is selected, we should not show operators to act on the selection, since this will fail.
In general the context menus are always meant to show the user relevant items for the current situation, so this fits with that concept.

When nothing is selected
For the case where nothing is selected, there often won't be very many applicable operators. In that case, we should add operators to add new items (objects, meshes, strips etc).

Regular menus

These we should keep constant, and not hide or show items, since it breaks muscle memory. Instead, we should use greying out. Preferably we should improve operator polling so that operators get greyed out when not applicable. When nothing is selected, or the wrong kind of item is selected, operatoers that don't do anything then should become greyed out.

Event Timeline

Some clarifications.

  • This is restricted to context menus "RMB or W-Key menus" (not other kinds of menus some users might think of as being context menus).
  • It would be good to expand on the case where nothing is selected, would it just have the "Add" menu included in the context menu? Or expand some adding actions into this menu? Or only include frequently used "Add" items?

    This might encourage an inefficient workflow, where users know to deselect to add new items. Instead of just using the shortcut to add items which is quicker and doesn't require de-selecting first.
  • How should linked library data be handled?

    For linked object data for example, it may be confusing to hide any menu items that act on object data, as an object which the user would see as a regular mesh - for example, would hide menu items which can't edit the mesh, instead informing the user that the mesh is linked and can't be edited.
  • How fine grained would this be?

    While it may seem obvious that an action may be useful or not.

    There are situations where hiding items is arguably correct but becomes confusing (may even seem like a bug from a user perspective).
    • Hide "Shade Smooth" if all meshes are already smooth.
    • Hide "Shade Smooth" if all meshes have no faces.
    • Hide "Duplicate Linked" if all objects selected are empties and this option has no meaning.
    • Hide separate by Material for a mesh with only a single material.

If this becomes difficult/confusing for users to reason about. We could use simpler logic in those cases.

Yes, at a certain point it is better to grey out.

For things like Copy/Paste, the Paste operator is only valid when there is something in the clipboard. I don't think we should hide Paste in that case, but just grey it out.

I think the rule should be that based on modes, object types and selection, we change what is shown. Based on deeper things like if the clipboard is filled or not, we use graying out.

Aaron Carlisle (Blendify) changed the task status from Needs Triage to Confirmed.Feb 28 2020, 4:14 AM