Page MenuHome

Use menus for operator search & various improvements
Closed, ResolvedPublicDESIGN

Authored By
William Reynish (billreynish)
Feb 24 2020, 11:05 AM
Tokens
"Like" token, awarded by viadvena."Like" token, awarded by EMeurat."Like" token, awarded by dpdp."Love" token, awarded by chironamo."Burninate" token, awarded by RomanKornev."Love" token, awarded by hitrpr."Love" token, awarded by satishgoda."Like" token, awarded by Alumx."Love" token, awarded by jonathanl."Love" token, awarded by vitorbalbio."Like" token, awarded by MantasKuginis."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.

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:

Layout

Many menu titles need the leading menus to give context. But to make it more readable, we can grey those leading menus out:

Revisions and Commits

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I know this was touched on before, but, some addons (like Carver) don't have anything in the interface at all and are just a hotkey. And some addons like the Remote debugger by @Sybren A. Stüvel (sybren) don't even have a hotkey and can only be accessed by the search menu.

IMO this is not an argument. The add-on was acceptable because it targets developers and could be found in the search menu. If the latter isn't true any more, the add-on just has to be updated so that it's usable again.

My point was that we have a diverse ecosystem of addons that don't all follow the same practices for interaction (even in the ones shipped with blender). Sometimes this is good, and sometimes it isn't, but it's what we have and what will likely continue. I think that rather than try to force addons to adopt better UI practices by reducing the search (which won't work entirely), we should just improve the search to aid discoverability as much as is possible. And both users and developers value using the search menu as a primary mode of interaction (I myself have a personal development addon with an operator that's only accessible through search because it's convenient).

I think it would be better to use a combination of the old and new methods and have a search that goes through menus and panels first (this adds location information and so aids in discovery, and allows for operators that have multiple actions) and then adds any missed operators to that. So we would end up with something that's more complete than either method on its own, that aids discovery, preserves the quick access to all operators, and prevents some of the issues that have been mentioned here because the search will have only gained functionality while not changing it's basic form.

@Dan Pool (dpdp)

  1. we are all against adding all operators to menus. It will be bad for interface and for addon developers.
  2. Menu shouldn`t mean only menu: search can show operators in addon-panels too like «N-panel > AddonTab > Addon subtab > Button name»
  3. If it will not be complete search, I am sure, it will be only alternative for operator seach, not the replacement.

I think that rather than try to force addons to adopt better UI practices by reducing the search (which won't work entirely), we should just improve the search to aid discoverability as much as is possible.

Agree, search (or one of it`s variants) should be as complete as possible or have options (rigt on the search popup) for switching between areas (only menus, menus and panels, all possible functions/operators).
May be checkbox to show/hide duplicates with rules, I wrote before

Asher (ThatAsherGuy) added a comment.EditedApr 22 2020, 6:03 PM

a) if there is direct specific shortcut way — show it first.
b) if it is in context menu — show it on the second place only if context is unique menu: right click in edit mode includes whole edge menu, so it is not unique
c) if it is in core menus (area or global) — show it next
d) if it is in specific place (N-panel, addon tab) show it only in case if it is not exist in core menus.

That degree of contextual filtering sounds tricky.

I'm still a fan of tagging individual menus as indexable/non-indexable, even if it leads to longer launch times. Since most of the bad search aliases come from hotkey-only menus, one option would be to add a 'searchable' property to the WM_OT_call_menu and WM_OT_call_menu_pie operators. That property could then be checked in menu_types_add_from_keymap_items(), removing those menus from the search results.

It wouldn't be a complete solution, but it's a way to implement rudimentary filtering without having to edit every single menu.

Edit: I threw P1352 together as a quick example. With it applied, try toggling the 'searchable' tag on relevant keymap entries to see how it changes the search results. The pivot mode pie menu is a great starting point, as it doesn't overlap with other menus.

That degree of contextual filtering sounds tricky.

Otherwise I would prefer manual filtering: core menues, addon panels, hidden operators, pies, quickfavorites…

tagging menus

  1. It adds more code noise
  2. How user can change tags? Should user change dozens of tags if he want another filtering behavior?

That is why I prefer smart filtering, but addon-creator can give a clue for smart system. For example he can add «pie» tag to pie-calling function (not to each operator).

dupoxy added a subscriber: dupoxy.Apr 25 2020, 7:21 PM

I believe since commit rBc46dcdf8871e7404516a234087cfc4bf4e2794d0, there is no way to find the "Make Instances Real" (object.duplicates_make_real) with the new search menu.

@dupoxy That does not appear to be the case. It works:

This comment was removed by dupoxy.

@William Reynish (billreynish) Yep it does works ... if you use the shortcut F3,
not if you use the menu Edit>Menu Search

@William Reynish (billreynish) Just to expand on dupoxy's comment. When opening the menu search from the top of Blender, it seems to only search the menus in the top of Blender. As far as I can tell this means the menu search is working as intended as it's searching the editor it was opened in (the top bar), but this isn't particularly user friendly.

One method to work around this is to remove editor specific searching, but this makes the search system a bit messy.

You could also try checking which editor was in use before the "Edit>Menu search" button was pressed and then search in that editor, but that may not always be the editor the user wants to search in.

Maybe the "Menu search" button should be added to the "Object context menu", the menu on right click when using the default keymap. "W" in right click to select keymap.

I'll leave the decision up to you and the other Blender developers. Just throwing some ideas out there.

dupoxy added a comment.EditedApr 26 2020, 4:04 PM

I tried to list context depending on editor type but to be clear it's all to fuzzy (for me anyway).
So I cam up with just adding the context to the search.
When you search you know the context depending on your cursor location.
The good thing is you can change it if its not what you want and for the Edit menu case it can be set to All contexts to help discoverability.
quick mock-up:

menu search context mockup

@Campbell Barton (campbellbarton) I think I found some inconsistencies...

  • The Knife tool (K) doesn't appear in the search (probably cuz it doesn't exist in the menus?)
  • None of the sculpting brushes/tools appear in the search either (again, probably cuz they doesn't exist in the menus?)

There are probably a lot more stuff missing that needs to be added to the menus so they can be searchable.
Maybe a devtalk thread to collect the missing stuff would help.

It’s never been the intention that you can do everything from searching. You can’t set any value or access operators outside the correct context. All brushes are not meant to be listed in the menus.

You can search for menu commands, that is what this is for. Switching brushes isn’t a command, so there is no inconsistency. Use the tools pop up for that.

It’s never been the intention that you can do everything from searching.

Not everything ofc, but it's expected that a search function like this, gives you access to almost all the commands and tools available in the application...

All brushes are not meant to be listed in the menus.

Why not? Most softwares do that... Even 2.7x had it in the menu... which made it easy to know what's available...


It's good practice to have almost all the tools/brushes/commands available in the menus as possible, for discoverability and intuitiveness reasons.
It's never good when things are scattered all over the place...

there is no inconsistency.

Well, the simple fact that the Knife tool is available in the right click context menu in edge mode, but not available in any of the main menus (mesh/vertex/edge/face) sounds very inconsistent, IMHO.

@TheRedWaxPolice (TheRedWaxPolice)
It is okay to have all in menu, but only when:
a) each level of menu is`nt overloaded, and separated
b) there is no more than 3-4 levels.
c) all hierarchy well organised, and logical

Otherwise, we can end up with something worse than that

I am not sure, that tools should be in menus. Because there is toolshelf and becausr it context-sensitive already.

I hope this hasnt been mentioned already (if so: sorry for the duplicate...), and maybe I am missing something, but following scenario seems pretty strange to me:

  • As an Addon developer while prototyping I dont add operators to menus [so I have to use Operator Search]
  • My operator relys on SPACE_VIEW3D context
  • Operator Search is accessible through the topbar [thus polling SPACE_VIEW3D context will fail if I launch my operator from Operator Search]

What is the intended way to do this now?

  • Should I be searching Operator Search in the 3DView Menu Search and then look for my operator there?
  • Or should I add Operator Search to Quick Favorites to be able to have SPACE_VIEW3D context?

In the beginning of the thread I suggested that menu search should be a separate thing from operator search, because I didn't want to see Operator Search fully gone, but after trying to live with two searches for a while, I now think that was a bad idea. I mean, I still want to have the functionality of Operator Search, but having it split into a separate search makes things frustrating; I ended up binding one search to Spacebar, and the other to Alt+Spacebar, only to end up opening the wrong one half the time.

So I would like to +1 to what @Dalai Felinto (dfelinto) suggested:

That said I think we could let "menu-less" operators to show when "Developer Extras" is enabled in User Preference.

Although I wouldn't even hide this functionality under Developer Extras, but that's me.

This comment was removed by Vyacheslav (hitrpr).

Interesting solution.
We are using search operator for tons of addons, that's why we use spacebar assignment.
Will results of previous search remain as well?
This is necessary for the sequential call of functions during linear work.
Quick favorites are not helpful that case, because list of operators is too long, and operations can be interrupted with some other actions depending on context to repeat it with repeat last operation.

@Paul Kotelevets (1D_Inc)
bpy.ops.wm.search_operator() always available.
To see Operator search in menu near menu search you need to activate Developers extras in 2.90.
It is possible to clear Space hotkey from new Menu search and assign to operator search (Already done it 4 myself).

Just so that the information is here as well:

Operators not in menus will now also show up in the new search bar when "Developer Extras" are activated.

@Sebastian Parborg (zeddb)
Oh, nice. So full search again! I like, that operator shown too. So we have choice between: Menu xor Menu+Ops (full) for one hotkey, Menu and Ops on separate hotkeys.

@Paul Kotelevets (1D_Inc)
What do you think: do search only for operators, those aren`t in menu can be handy? Now operator seach (obviously) includes all operators.
I don`t need it. But may be someone?

Operators not in menus will now also show up in the new search bar when "Developer Extras" are activated.

That's interesting) Thank you for response.

Just so that the information is here as well:

Operators not in menus will now also show up in the new search bar when "Developer Extras" are activated.

This is great!

One thing I noticed (and this affects the old operator search as well) is that hotkey only operators don't display their hotkey. For example, object.hide_collection. This operator only works properly when called from hotkeys (1, 2, 3, etc.). It shows up in search, which is good, but since it doesn't show its hotkey it doesn't help in finding this feature. If it's possible I think adding in hotkeys for hotkey only operators would help discoverability a lot.

Anyway, with the operators that aren't in menus added back in I think this is a good improvement to the search menu. Thanks to everyone involved working on this. :)

Propose this task be closed as complete, remaining improvements be split out into their own tasks.

Great!
I assume, that context menu for search is another task, is it?

Hello! I updated the diff that was mentioned here earlier.
Here is the latest demo and updated diff: D6813: Searchbox wrap around feature

I can not find Scatter Object in the Menu Search.

I can not find Scatter Object in the new Menu Search.

I can not find Scatter Object in the new Menu Search.

check addon filter

Is there anything missing here? If so, suggest updating the description with remaining TODOs.

Moving to short-term category, since this is mostly done.

Vyacheslav (hitrpr) added a comment.EditedJul 10 2020, 7:00 AM

@Julian Eisel (Severin)
Looks like it done mostly:
Menu search with paths.
Full (operators) search with dev. extras.
Hotkeys.
Quickfav and new shortcut from context menu.

The only one thing is bothering me — alignment of few hotkeys. Note Ctrl+P On the right

Why it is there? Looks strange and uncomfortable to read.
So it needs some more testing and polishing.

Looking at the design in the original post, these things are still missing I think:

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

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

There were also some great suggestions from people in the thread and I can only hope they were considered. For example, these suggestions get a big +1 from me.

  • Zebra striping.
  • Open it centered rather than following mouse since it is necessarily large.
  • Do not fill search box with prior search result.

(I also think zebra striping would address the hotkey uncomfortableness T74157#976364)

This task was too broad, mixing different issues, not enough of the details were properly discussed and it's difficult to follow.

I'd rather this be closed and remaining issues moved to their own tasks.

Well, closing this task as resolved will turn its current state to determined, that will be useful for further development, so why not.

That was long, and I'm not sure this was addressed:

SEARCH hotkey results being cursor-context sensitive - it's confusing. My goto example is Searching for SHEAR over the 3dView gives the hotkey(s), over the Properties window it does not. This is confusing.

I think Search results should always show the same thing. If it's required that the cursor be over a specific window to function, that info should be in the Search results, so that every Search gives the same result no matter the position of the cursor.

My current thoughts...

  • Do not fill search box with prior search result.

Can you, please, explain the reasons behind that decision?
Search box is used for calling addon operators, filling search box with prior search result it is the fastest way to call operator during repetative work.
This is the reason the search menu is usually used - the fastest call.
Try to call the same operator 50 times in a row with and without prior search result to feel the difference.

@Paul Kotelevets (1D_Inc) I was confused about this suggestion initially also, but it was later explained; the suggestion isn't to always start the search bar empty, but to keep the previous search query, rather than the previous search result. Eg., in your screenshot, if you press enter and then search again, the search query will change from "cube" to "Add -> Empty -> Cube", and since that's the query, there will only be a single result. The idea is to just keep the query "cube", so the workflow you describe should be mostly unaffected I think.

The idea is to just keep the query "cube", so the workflow you describe should be mostly unaffected I think.

Thank you for explanation. It is very important issue, so we would like to know it for sure.

W means Workflow.

I experiencing some constraints in new design of F3 search bar. Previously we could use commands in cross modes workflow. For example: "Limit Number of Weights per Vertex" I could use this command in object mode for all selected objects before. But now I must to enter in Weight Paint mode for each object every single time and execute this command. Routine is multiplying.

Another example: "Separate" similar to Separate (By loose parts, selected, by material) in Edit mode. It's very handy when you can separate independent pieces by individual objects from very High-Poly mesh without needing to enter in Edit Mode. We all know how slow Blender in Edit Mode for High-Poly meshes so I waste long time to enter in Edit Mode, then I waste time while Blender separating object. Double time!

And there is no "Save Preferences". Why? Auto-save preferences is not a solution for me because I am experimenting all the time...

I don't like how Blender trying mimic Maya and turning to be a toy for a kids. I use Blender since 2012 and I loved how F3 showed hidden commands or commands which being in different modes and bring you power similar to terminal in Linux. Now F3 shows exactly the same that you can find on the screen in the tabs. So F3 useless for me. I hope you guys will take care of it.
Out of this topic I really love 2.8 interface, it's very fresh and beautyful.

And there is no "Save Preferences". Why? Auto-save preferences is not a solution for me because I am experimenting all the time...

@Aleksandr (viadvena)
And what is this?

W means Workflow.

Previously we could use commands in cross modes workflow.

Fair enough.

And there is no "Save Preferences". Why? Auto-save preferences is not a solution for me because I am experimenting all the time...

@Aleksandr (viadvena)
And what is this?

It took some time a year ago to explain that preferences that requires coding should have such an option.
Well, it was made not that obvious, so it is easy to be confused.

I don't like how Blender trying mimic Maya and turning to be a toy for a kids.

There is a fine line between "industry standards compatibility" and "mimic Maya", and, indeed, sometimes this line is broken very roughly.

Out of this topic I really love 2.8 interface, it's very fresh and beautyful.

It didn't changed much, it is more dark and more Maya/ISS.

I experiencing some constraints in new design of F3 search bar.

F3 for searchbar is animators setup, modellers setup is spacebar.

This is the reason the search menu is usually used - the fastest call.

There would be nice to have double spacebar (or current search popup hotkey) press to quickly execute prior search result.
This will be very useful for repetitive work.
Such a behaviour can be considered as part of this proposal.

Legacy search is still available. I believe you have to enable developer extras. I have old style search assigned to f3 key and new search assigned to space bar.

Dan Pool (dpdp) awarded a token.

And there is no "Save Preferences". Why? Auto-save preferences is not a solution for me because I am experimenting all the time...

@Aleksandr (viadvena)
And what is this?

I told about this...

W means Workflow.

I experiencing some constraints in new design of F3 search bar. Previously we could use commands in cross modes workflow. For example: "Limit Number of Weights per Vertex" I could use this command in object mode for all selected objects before. But now I must to enter in Weight Paint mode for each object every single time and execute this command. Routine is multiplying.

While you could access this in object mode, it didn't run on all selected objects. This is an example of why simple searching through operators doesn't work well if perform operations in a way you might expect - given some operators are written to be accessed in spesific contexts.

I've since added an "Object -> Clean Up" menu to access these kinds of operations, that perform on multiple objects, see:

Another example: "Separate" similar to Separate (By loose parts, selected, by material) in Edit mode. It's very handy when you can separate independent pieces by individual objects from very High-Poly mesh without needing to enter in Edit Mode. We all know how slow Blender in Edit Mode for High-Poly meshes so I waste long time to enter in Edit Mode, then I waste time while Blender separating object. Double time!

This could be exposed to a menu, I'd need to look into it though.

And there is no "Save Preferences". Why? Auto-save preferences is not a solution for me because I am experimenting all the time...

We could have save/load preferences in the defaults menu, I don't have a strong opinion on this.

I don't like how Blender trying mimic Maya and turning to be a toy for a kids.

This wasn't trying to mimic other software, we had many bug reports about accessing operators from a list not work well (over the years). Searching through menu items is a fairly obvious way to lookup functionality.

I use Blender since 2012 and I loved how F3 showed hidden commands or commands which being in different modes and bring you power similar to terminal in Linux.

You can still access the operator search if you want, it's an option for the operator that opens this popup.

Now F3 shows exactly the same that you can find on the screen in the tabs. So F3 useless for me. I hope you guys will take care of it.

Each issue needs to be taken care of on a case-by-case basis, if you think there are other items missing from menus, let us know.

@Campbell Barton (campbellbarton) Thanks a lot for adding this features! This is exactly what I was missing. If it possible would be awesome to get notifications after command proceeded.

Split out remaining todo's into their own tasks as the majority of this proposal has been completed: T80422: Proposal to highlight menus during menu search, T80423: Proposal to show empty search results when the text field is empty.

HI!
What happened to the search on f3. The addon by its own (as it was before) name can no longer be found.


It is very uncomfortable. Nobody can find my addons in this list. Please correct

HI!
What happened to the search on f3. The addon by its own (as it was before) name can no longer be found.

There is operator search and menu search now.
When Developers Extras off, operators search (full search) is unavailable

That's pretty strange, because operators are written by developers, but used and searched by users.
This allow to them to avoid endless addons section scrolling.

Aleksandr (viadvena) added a comment.EditedSep 28 2020, 1:00 PM

@Campbell Barton (campbellbarton) Could you please add Separate feature which I describe above. I forgot to ask you about this earlier because most of the time I using 2.83 in studio.

"Separate" similar to Separate (By loose parts, selected, by material) in Edit mode. It's very handy when you can separate independent pieces by individual objects from very High-Poly mesh without needing to enter in Edit Mode. We all know how slow Blender in Edit Mode for High-Poly meshes so I waste long time to enter in Edit Mode, then I waste time while Blender separating object. Double time!

May be in the same place as others Object -> Clean Up?

HI!
What happened to the search on f3. The addon by its own (as it was before) name can no longer be found.
It is very uncomfortable. Nobody can find my addons in this list. Please correct

This is documented in the 2.90 release notes. In short: add your operator to a menu, and it'll be found by users with F3.

This is documented in the 2.90 release notes. In short: add your operator to a menu, and it'll be found by users with F3.

Blender's own templates_py/operator_*.py files need this.