In general, am not against this, noting some issues though.

• Limiting 'Add' or 'Reveal' to only show when there is no selection seems a bit odd.
  
  There might even be good reasons to keep the existing selection, add new items - then group them for eg (nodes or objects).

• Current code checks selection count, while this seems reasonable. Would we consider it an *improvement* to do more comprehensive checks?
  • 'triangulate' could check if all faces are already triangles.
  • 'clear parent' could check if any objects have parents.
  • 'set origin' could check if there is any geometry selected and hide menu items which depend on geometry.
  • Many operators could be hidden if for example the mesh has no faces or no edges.
    
    The issue with this is, there is a limit to what we should reasonably check for when when showing a menu. Even if it's just the limit of Python to be able to detect these cases on heavy scenes.
    
    If we wanted we could have a different kind of poll function where operators can perform more extensive checks, but this seems like it could be over-kill.

• Items showing in menus should not seem 'random' from a user perspective.
  
  When a user follows a tutorial for example, and a menu item referenced in the tutorial doesn't show up - it could be very confusing. In some cases it could be better to show the menu item, then give a message about why the tool doesn't work (especially if the reason isn't straightforward ~ needs custom-normals layer, needs at least one other mesh object selected...).
  
  Keeping this checks to vert/edge/face selection seem safe, just noting that more comprehensive checks might seem clever, but end up being confusing from users perspective since they wont get any hints to why the operation is missing.

• A down side to having items come and go too much in a menu is the key accelerators change.
  
  If checks are too fine grained, activating the menu might show a set of options that seem unfamiliar (making access require more thinking each time).

In D4043#91451, @Campbell Barton (campbellbarton) wrote:

In general, am not against this, noting some issues though.

• Limiting 'Add' or 'Reveal' to only show when there is no selection seems a bit odd.

Yes, we could add more here - it looks a bit bare with just the two, I agree.

There might even be good reasons to keep the existing selection, add new items - then group them for eg (nodes or objects).

• Current code checks selection count, while this seems reasonable. Would we consider it an *improvement* to do more comprehensive checks?
  • 'triangulate' could check if all faces are already triangles.
  • 'clear parent' could check if any objects have parents.
  • 'set origin' could check if there is any geometry selected and hide menu items which depend on geometry.
  • Many operators could be hidden if for example the mesh has no faces or no edges.
    
    The issue with this is, there is a limit to what we should reasonably check for when when showing a menu. Even if it's just the limit of Python to be able to detect these cases on heavy scenes.

Agreed - there is probably a limit to how far we can reasonably go in terms of cleverness.

Mainly I think the big thing to improve is better context in relation to selections. In Curve Edit Mode, you can only create segments from curve endpoints. In Mesh Edit Mode, you can only bridge faces if two are selected. Those kinds of things would be nice to add.

But, yes, checking for the set origin thing and probably the triangulated faces thing is probably not necessary.

If we wanted we could have a different kind of `poll` function where operators can perform more extensive checks, but this seems like it could be over-kill.

• Items showing in menus should not seem 'random' from a user perspective.
  
  When a user follows a tutorial for example, and a menu item referenced in the tutorial doesn't show up - it could be very confusing. In some cases it could be better to show the menu item, then give a message about why the tool doesn't work (especially if the reason isn't straightforward ~ needs custom-normals layer, needs at least one other mesh object selected...).
  
  Keeping this checks to vert/edge/face selection seem safe, just noting that more comprehensive checks might seem clever, but end up being confusing from users perspective since they wont get any hints to why the operation is missing.

Yes, so the way I think about this, is that this is the contextual menu. It's already quite contextual. We have alternative menus, such as Ctrl-V, Ctrl-E, Ctrl-F which spawn the vertex, edge and face menus with a static list of commands that don't change.

The role of the contextual menu is different - it's to be as contextually intelligent as reasonably possible.

Re. your code comments, I obviously agree because by default I defer to you completely in this area.

Hi. While this might be good, this is also very dangerous for the discoverability of features. I'd rather have the commands there either greyed out or giving a warning when they can't be used. IMHO.

Looks good to me.

After discussing this with Julien Kaspar, I think we can add a few more commands still, so that all the main mesh modeling commands are available. I can easily do this.

@Campbell Barton (campbellbarton) question:

How can we add these kinds of checks to Curve Edit Mode and UV Editor? If you can make a quick template or example, I can fill it out more.

I like the idea a lot.
But couldnt we rely on operators poll() more here?
I guess this is what you meant by saying

If we wanted we could have a different kind of poll function where operators can perform more extensive checks, but this seems like it could be over-kill

but I am not sure why this would be a differnt kind of poll? Couldnt all these checks be done in that one existing poll?

If I understand correctly poll() is executed anyways [greying menu entries out when failing], so instead of doing decoupled checks in the menus themselves, should we pay more attention to putting these checks into the poll() of the corresponding operators?

• we could then still decide if a failing poll would only grey out the menu entry or remove it entirely [this could be a user preference even]
• downside: if there are performance costly checks, these would be executed multiple times [e.g. a checking verts_len would be done for both mesh.merge and mesh.remove_doubles in their poll (instead of just once in the menu code)]
• upside: most operators polls are C [so more performant than py I guess]
• upside: there is only one place in the code that is responsible for decission of whether or not this operator makes sense to be executed
• downside: could lead to a lot of duplicated code in many operators poll functions (but I guess utility functions could be written for all operators to use)
• upside: the operator search popup would also respect that [looks like this filters out operators for that poll fails?]

+1 for putting more operators in the [context] menus btw.

@Philipp Oeser (lichtwerk): Forgive me if I'm wrong, but isn't it much less efficient to perform the check for each individual menu item, as opposed to checking once for a section of commands in the menu?

@William Reynish (billreynish) : yes, thats what I was also worried about

downside: if there are performance costly checks, these would be executed multiple times [e.g. a checking verts_len would be done for both mesh.merge and mesh.remove_doubles in their poll (instead of just once in the menu code)]

I could do a quick check and see how it goes for e.g. checking how many vertices are selected say for 10-15 operators on a fairly highpoly mesh?

Yes I suppose that would be very useful, although perhaps @Campbell Barton (campbellbarton) would already know the relative difference?

In any case, such a test wouldn’t hurt.

Also could use CTX_wm_operator_poll_msg_set to our advantage here (so lets say when we just grey out the menu entries, we could add this hint to the tooltip, explaining why the menu entry is greyed out...)

@Philipp Oeser (lichtwerk): Well, for these contextual menus, we should show/hide things and not just grey out. Otherwise the menu may get 200 items long, and besides, the role of this is to be contextual, not to show everything.

Using operator poll function vs a poll in the UI: I have no preference, although the operator poll functions requires me to do it in C which I can't do :) But if someone else was to help with that part I also don't mind - my only goal with this is to make it so that the contextual menus are more contextual.

I love you guys.
I believe the level of the work has reached this level:

In D4043#91678, @Philipp Oeser (lichtwerk) wrote:

I could do a quick check and see how it goes for e.g. checking how many vertices are selected say for 10-15 operators on a fairly highpoly mesh?

It is too slow, as a rule we do not do such expensive checks in poll functions. For example the search operator runs thousands of poll functions, and any toolbar with these operators would run it on every UI redraw.

It's possible to make these fast if information about number of selected elements is stored in the edit mesh data structure, that might be some work to track though.

just wanted to point out that converting mesh to mesh is in fact really useful as a way to apply multiple modifiers... btw convert mesh to curve will only work if you have some edges with no faces connected, should you check that too? but it's a great move anyway, I'm all for it

It is too slow, as a rule we do not do such expensive checks in poll functions. For example the search operator runs thousands of poll functions, and any toolbar with these operators would run it on every UI redraw.

oki, thx for clarifying

In D4043#91728, @Brecht Van Lommel (brecht) wrote:

In D4043#91678, @Philipp Oeser (lichtwerk) wrote:

I could do a quick check and see how it goes for e.g. checking how many vertices are selected say for 10-15 operators on a fairly highpoly mesh?

It is too slow, as a rule we do not do such expensive checks in poll functions. For example the search operator runs thousands of poll functions, and any toolbar with these operators would run it on every UI redraw.

It's possible to make these fast if information about number of selected elements is stored in the edit mesh data structure, that might be some work to track though.

Even in this case, you need to loop over all edit-meshes for every poll call.
We could do it by storing selection count information (the kind of information thats already in the status bar), but this complicates operator execution since we'd need to keep this valid between operator calls.

For a operators that call other operators, macro or Python scripts for eg, we never know which poll will need to check selection, so we would need to keep it valid, or invalidate it and lazy initialize it when the poll function requests it via an API call.

Even though all this is possible, there are further complications...

Operator macros for eg, check if the operators poll functions succeed, only running if all of them do. If a single operator is a nop. it's harmless at the moment, if poll functions are inspecting data, it could cause annoying corner cases where macros fail.
Worse, a macro may fail because the initial operators haven't yet been run to setup a valid state which other operators test.

If a Python script calls remove-doubles, an exception will be raised (if the only have one vertex selected or similar kinds of cases).
This makes script authors need to be aware of the situations where an operator might do nothing, and check for it in their code.

Since the use case for optionally showing menu items is limited to context menus, I'd rather limit it to checking in the menus, or have a separate kind of poll function.

thanx again for detailed explanantion

In D4043#92587, @Campbell Barton (campbellbarton) wrote:

Tested the new menu, people will need to rotate their HD monitors to be vertical if they want to mix 2-3 modes.

Think the menus are unreasonably tall.

We could look into having 3x columns while still using a menu (like adding modifiers does already).

Great idea, I hadn't thought of that. I only tested when using each selection mode separately, not combined. Nice solution with the columns

I will update it to do this and fix the other issues.

Contextual menu in Edit Mode:

Vertex

Edge

Face

All 3 at the same time:

Applied patch rB7312e48ae43e32f4d7c95a6d170861abbf03190d except for space_outliner.py.

The outliner is referencing 3D view operators that use object selection, not outliner selection, so "Delete" uses one kind of selection, "Copy" another.

This should be resolve before adding copy/paste into the outliner context menu.

Closing the patch since nearly everything has been committed, copy/paste in the outliner can be handled separately.