Menus & Context Menus: What to do if operators aren't valid #74158

New Issue

William Reynish · 2020-02-24T11:16:13+01:00

William Reynish commented

2020-02-24 11:16:13 +01:00

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.

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.

William Reynish self-assigned this 2020-02-24 11:16:13 +01:00

William Reynish commented

2020-02-24 11:16:13 +01:00

Added subscribers: @WilliamReynish, @ideasman42

Campbell Barton commented

2020-02-24 12:31:06 +01:00

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.

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.

William Reynish commented

2020-02-25 12:49:36 +01:00

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 typesand selection, we change what is shown. Based on deeper things like if the clipboard is filled or not, we use graying out.

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 commented

2020-02-28 04:14:51 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Chris Kohl commented

2020-05-23 12:18:00 +02:00

Added subscriber: @ckohl_art

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Menus & Context Menus: What to do if operators aren't valid #74158

Context menus

Regular menus