Page MenuHome

Use menus for operator search & various improvements
Confirmed, NormalPublicDESIGN

Tokens
"Like" token, awarded by aditiapratama."Love" token, awarded by irfan."Like" token, awarded by Imaginer."Like" token, awarded by brezdo."Love" token, awarded by Tetone."Like" token, awarded by JulienKaspar.
Authored By

Description

Currently the operator search popup has a few issues:

  • You can't search for UI names, meaning menu items such as Clear Seam aren't searchable (because it's internally just an option for Mark Seam)
  • You cannot right-click on search items to add shortcuts or to add them to the Quick Favorites
  • You cannot see in which menu the item lives
  • We often show operators that don't work in a given context

We can solve this by fundamentally changing the way we search. Instead of searching all operators, we can simply search the menus instead. This means we could search for 'Clear Seam' and find it, and it also means we can tell users which menu it is in, and we can make it so the search results act like normal menu entries with properly working context menus.

At the same, we can improve the search UI a bit:

Before typing, instead of listing all operators, just keep the UI more compact, like so:

When the user searches, the popup expands:

We can now search for UI menu names in addition to the operator names, so we can find things like Clear Seam:

For each search result item selected, we highlight the menu where it lives. In this case Clear Seam is in the Edge menu:

Because we are just showing menu entries, we can now also support the normal menu item context menus, so items can be added to Quick Favorites and assigned to shortcuts:

Revisions and Commits

Event Timeline

Instead of searching all operators, we can simply search the menus instead.

This seems fine as long as we first ensure all operators are actually accessible through menus.
If I'm not mistaken there were still quite a few more obscure ones which are only accessible through search.
It is currently hard to add keyboard shortcuts to some of my frequently used items, it would then make them totally inaccessible and undiscoverable.

For example Set Curve Radius bpy.ops.curve.radius_set is not currently in any menus, as far as I can tell, there are probably others.

Before typing, instead of listing all operators, just keep the UI more compact, like so:

Perhaps it would be more useful to present a progressively populated short list of recently used operators (maybe limited to a certain count) instead.

Not sure if this is within scope here, but when reopening the search menu it currently shows only the last used operator. It seems more useful to present last search term results instead.
If I search for "edge loop" it presents three operators, but if I use one of them and reopen the search bar it only shows the last used operator alone instead of the three results.
If I use non of them and reopen the search bar it will show a completely different previously used operator.

This might well be a personal preference, but I'd say it would be more useful to always show last used search term and results. One might even strategically use search terms to show a particular selection of useful operators used in sequence.

Searching all operators is very important for the obvious reasons, so make sure this option will still be there somehow.

Can't trust the menus only.

Searching all operators is very important for the obvious reasons

Currently we show lots of operators in the search menu that's simply don't work. That is not 'important' - it is wrong, and could be classed as a bug. We don't want to present users with items that don't work at all, or aren't set with useful defaults, as happens with many operators when they are called without an argument.

Can't trust the menus only.

Why can't you trust menus? If something useful is missing from the menus, it should be added anyway.

@William Reynish (billreynish) Maybe it's better to show the operators but greying them out if they can't be executed?
I think it's still very important to find the thing I'm searching for, otherwise I would think it's gone.

So with this there will be no way to search for custom python operators that are not available on the menus?

I'd still prefer to have an option to search all operators, even if it's hidden in the preferences...

How would this work for add-ons? Would add-on developers have to create arbitrary menus in order to make their operators accessible via search? Would there be a way to filter which menus would be included in the search scope?

Operator aliases and search-executable presets would be more robust; it'd take a fair bit of grunt work, though.

@TheRedWaxPolice (TheRedWaxPolice) Python operators can add themselves to a menu.

@Asher (ThatAsherGuy) add-on developers should add their operators in Blender's existing menus.

This seems fine as long as we first ensure all operators are actually accessible through menus.
If I'm not mistaken there were still quite a few more obscure ones which are only accessible through search.
It is currently hard to add keyboard shortcuts to some of my frequently used items, it would then make them totally inaccessible and undiscoverable.
For example Set Curve Radius bpy.ops.curve.radius_set is not currently in any menus, as far as I can tell, there are probably others.

I think it's reasonable to expect all operators to be added to menus, I can't think of an example of an operator which should be search-only.

Generating a list of operators not accessible via menus can be automated, there will be a handful we accept aren't accessible since they're very specialized (such as reordering shape keys).

The rest can be added to menu items.


If for some reason this proves insufficient, we could have a workaround that allows operators to be added to some searchable menu. I see that more as a last resort though - something to avoid.

I can think of cases when I'd rather not have to bother adding my operator to a menu just to make it searchable, particularly when developing the addon mainly for myself or my friends or my team, or when the addon is a single operator that doesn't really belong anywhere in the UI, etc. Is there really no other way to allow us to set shortcuts from the search menu? How come? Are we sure we're fixing the root of the problem here?

If this is the only way, then I would expect that registering an operator and placing it in the UI should be possible to be done in one step, or throw an error if an operator was not placed in the UI.

This could also end up increasing the barrier for entry for addon developers, since you'll have to learn how to add things to the UI before you can make a custom operator. This probably doesn't sound like a big deal to most people here, but I think it should be kept in mind.

But I'm super happy that we're trying to get the ability to add shortcuts from the search menu - that would be huge!

@Demeter Dzadik (Mets) The root issues are:

  • You can't search for UI names, meaning menu items such as Clear Seam aren't searchable (because it's internally just an option for Mark Seam)
  • You cannot right-click on search items to add shortcuts or to add them to the Quick Favorites
  • You cannot see in which menu the item lives
  • We show many operators that don't work in a given context

The solution here solves all of these.

Some of those sound like symptoms, not the root cause.

  • Why is it that we can't right click and add shortcut to things in the current search menu in the first place?
  • Why do we show operators that don't work in a context? This just sounds like bad poll functions, not the search menu's fault. In this case it would make sense to leave this responsibility to the developer/addon developer of the operator.

I also want to throw out there the idea of letting Operators be aware of where they were added to the UI. This way, the search could still search among all available operators - And as a bonus, do extra fancy stuff, IF that operator exists in the UI; Such as highlight where it is, display multiple copies of the operator with different names and parameters(Clear/Mark Seam) and be able to set a shortcut with right click (still wonder why being in the UI is required for this though).

I can think of cases when I'd rather not have to bother adding my operator to a menu just to make it searchable, particularly when developing the addon mainly for myself or my friends or my team, or when the addon is a single operator that doesn't really belong anywhere in the UI, etc.

Not sure if it is possible, but perhaps do it at runtime

Generating a list of operators not accessible via menus can be automated,

Maybe after polling menus then automatically generate on-the-go a dynamic list of any remaining missing operators to be appended to the searchbar pool.

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

Some of those sound like symptoms, not the root cause.

  • Why is it that we can't right click and add shortcut to things in the current search menu in the first place?

This is a red-herring IMHO - it could be supported with the current search popup.

  • Why do we show operators that don't work in a context? This just sounds like bad poll functions, not the search menu's fault. In this case it would make sense to leave this responsibility to the developer/addon developer of the operator.

The issue isn't exactly that operators don't work, it's that they don't work usefully.

The main issue I've run into is operators which need to be called with arguments, the menu items set useful arguments - but the operator on it's own doesn't do something useful.

An example of this: T73711: Give Make Single User sensible defaults.

I also want to throw out there the idea of letting Operators be aware of where they were added to the UI. This way, the search could still search among all available operators - And as a bonus, do extra fancy stuff, IF that operator exists in the UI; Such as highlight where it is, display multiple copies of the operator with different names and parameters(Clear/Mark Seam) and be able to set a shortcut with right click (still wonder why being in the UI is required for this though).

This is possible of course, you could show the operator, then the different menu items that call it. Although I'd be more inclined to implement something similar - list all operators as we do now - if they aren't in any menus.

This is a red-herring IMHO - it could be supported with the current search popup.

That's great to hear! This should have always been a thing then!

list all operators as we do now - if they aren't in any menus

I call many operators from operator search that also exist in other menus, so I don't like this idea. For me, operator search is not a last resort type of thing for when I've looked through every single menu and couldn't find what I needed. Instead, it's where I look first, because it's fast and convenient. One of my favourite features in Blender!

The main issue I've run into is operators which need to be called with arguments

Fair enough, finding things that are useless, is useless. But just because an operator wasn't added to the UI doesn't mean it doesn't have usable defaults. Most operators should have usable defaults, and the ones that can't, should use exactly the solution that you've applied in that patch - pop-ups. Since the pop-up only gets called from operator search, it seems like an ideal solution.

I can see that there actually are some operators that really can't be made use of by calling them from operator search, eg. bpy.ops.paint.weight_paint. For these cases, how about a bl_option to hide the operator from search? Ideally something like this wouldn't get used unless absolutely necessary, since there should be very few cases like this.

Added initial menu-scanning search implementation D6984: Use Menus for operator search.


I call many operators from operator search that also exist in other menus, so I don't like this idea. For me, operator search is not a last resort type of thing for when I've looked through every single menu and couldn't find what I needed. Instead, it's where I look first, because it's fast and convenient. One of my favourite features in Blender!

Point taken, even so - ensuring features are not only discoverable via search but are also in menus seems like a net-gain in usability.
We can always re-evaluate this kind of decision along the way, I'm not worried about lack of feedback for this one :)

I can see that there actually are some operators that really can't be made use of by calling them from operator search, eg. bpy.ops.paint.weight_paint. For these cases, how about a bl_option to hide the operator from search?

We have this, it's called OPTYPE_INTERNAL & should be set for all operators which don't do anything useful.

Campbell Barton (campbellbarton) renamed this task from Operator Search to Use menu's for operator search & various improvements.Mon, Mar 2, 4:21 AM
William Reynish (billreynish) renamed this task from Use menu's for operator search & various improvements to Use menus for operator search & various improvements.Mon, Mar 2, 8:34 AM

rBc46dcdf8871e: UI: add menu search functionality to operator search menu has been committed, now we need to see if this would be reasonable to replace the current operator search in it's current form.

Tested in master! Thanks for putting it in as an experimental feature so it's easy to test.

To reduce the clutteredness of it, I wonder if it would be possible to have an outliner-like hierarchical structure happening:


(excuse the crude mockup made with a screenshot tool...)
An idea on top of this is to have the entry which contains further entries stick to the top of the window until we've fully scrolled past its contents. But that might feel clunky in practice. Also raises questions on how to handle when things are nested several times. Ohwell, an idea.

And while this menu search seems very useful, it definitely shouldn't replace Operator Search, but be its own thing instead. Ideally we could set a separate shortcut for Operator Search vs Menu Search, and in the future new users would probably be recommended to use Menu Search. The idea of having a single shortcut for both, and then having to click to switch between them, sounds clunky to me.

Also looking forward to being able to right click and assign shortcut!

+1 for having all operators searchable unless explicitly excluded (regardless of whether they're in the UI).
Iirc, the template operators in the text editor aren't assigned to the ui and wouldn't be callable if the search was UI only.

Everything else sounds great to me!

On a slightly different topic, what would be the possibility of adding support for tooltips for this and all search menus?

For the UI, may I suggest de-emphasizing the menu path a bit? I would suggest something like this (from Alfred on macOS): https://www.alfredapp.com/media/whats-new/internal-prefs-search-custom.png

That way it is much easier to find what you were actually searching for.

@Demeter Dzadik (Mets), an issue with what you're suggesting is there wont always be room for the full hierarchy for nested menus. Although having the menu path repeated all over is a bit heavy too.

This also means we would need un-selectable items in the list which are only container types.

Adding tooltips is possible.

@Wouter Stomp (wouterstomp) de-emphisizing menu path seems OK, although I'm not sure we would want them to take up so much space.

Quick feedback on the current implementation.

I generally can see this being useful, so definitely +1.
Before this becomes the default, I'd suggest improving the visual side of this though. The menu feels quite crowded and clunky to me right now, much less professional to be honest. Icons also seem blurry, I think they are smaller than the default size?

The menu path should indeed be de-emphasized I think. It helps a lot to put it into a separate line, although that of course increases the menu size significantly. I'd at least try this though, I actually don't think it will be much of an issue.
We could also have a line in the popup that always shows the path of the currently highlighted item, or we only show the path on hover. I will leave this up to the designers though :)

My current thoughts...

  • Icons on the left should go as they are not associated with the menu name beside it, but with the item at the end of the line.
  • Use menu submenu triangle to separate the parts.
  • Zebra striping.
  • Open it centered rather than following mouse since it is necessarily large.
  • Do not fill search box with prior search result.

Do not fill search box with prior search result.

I rely on this behaviour a lot, would be sad to see it go without good reason.

I think the icons could be used if the menu path was separate from the... let's call it "button name".

Current operator search already has three columns: Category, Operator name, Shortcut. Why not do something very similar here? Menu path, Button name (with icon), Shortcut.