Use menus for operator search & various improvements #74157
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
39 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#74157
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently the operator search popup has a few issues:
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:
{F8366112, size=full}
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:
Added subscribers: @WilliamReynish, @ideasman42
#76116 was marked as duplicate of this issue
#75660 was marked as duplicate of this issue
Added subscriber: @DuarteRamos
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_setis not currently in any menus, as far as I can tell, there are probably others.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.
Added subscriber: @JulienKaspar
Added subscriber: @ThinkingPolygons
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.
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.
Why can't you trust menus? If something useful is missing from the menus, it should be added anyway.
@WilliamReynish 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.
Added subscriber: @TheRedWaxPolice
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...
Added subscriber: @ThatAsherGuy
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 Python operators can add themselves to a menu.
@ThatAsherGuy add-on developers should add their operators in Blender's existing menus.
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.
Added subscriber: @Mets
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!
@Mets The root issues are:
The solution here solves all of these.
Some of those sound like symptoms, not the root cause.
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).
Not sure if it is possible, but perhaps do it at runtime
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.
Changed status from 'Needs Triage' to: 'Confirmed'
This is a red-herring IMHO - it could be supported with the current search popup.
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: #73711 (Give Make Single User sensible defaults).
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.
That's great to hear! This should have always been a thing then!
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!
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 abl_optionto 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.
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 :)
We have this, it's called
OPTYPE_INTERNAL& should be set for all operators which don't do anything useful.Operator Searchto Use menu's for operator search & various improvementsUse menu's for operator search & various improvementsto Use menus for operator search & various improvementsc46dcdf887has been committed, now we need to see if this would be reasonable to replace the current operator search in it's current form.Added subscriber: @JulianEisel
Related: D6813: Searchbox wrap around feature, D1546: Search Menu Tooltip Patch
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...)
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!
Added subscriber: @Imaginer
+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?
Added subscriber: @blenderrocket
For the UI, may I suggest de-emphasizing the menu path a bit? --screenshot removed-- That way it is much easier to find what you were actually searching for.
@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.
@blenderrocket 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 :)
Added subscriber: @Harley
My current thoughts...
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.
I don't mind if the search box contains the last search text, but not the last search result.
What I mean is I can search for "Add", then select one of the items from the list. When I launch search again I don't mind if the search box contains "Add" with the same results as previous. But I don't like the current behavior where the search input box contains all of "Add > Mesh > Cube" with just that same single result.
Unless there is something about this behavior I am missing, since we already have a "Redo Last" operator.
Added subscriber: @HooglyBoogly
The utility here is that often you have to search for a rarely used operator, do some other things, then use the soperator you searched for again. "Redo Last" wouldn't work there.
Since it doesn't slow down doing a new search, I would vote for keeping the search box filled with the prior search initially.
Yes this is what I mentioned earlier and I very much endorse this behavior rather than the current one, present last search term rather than last used operator is a lot more useful
For sure. Now wondering if it might be nice to have a little dropdown to the right of the search box containing a list last-searched results. That way the search input box could contain last searched text (only), while the dropdown would contain some number of the items you have clicked on.
Ah yes, this makes sense to me too actually - I thought you meant that the search box should always start completely empty.
Added subscriber: @DanielGrauer
not sure if this is the correct place to report this, but when the experimental menu search is enabled the "Debug Menu" will not appear.
Added subscriber: @fsiddi
Added subscriber: @dfelinto
The way I see it, the use case Demeter brought up (to show all operators even if not in a menu) is really a hack, useful during add-on development. That should not dictate the feature as presented to the final user. I second what Campbell said here, any operator should be discoverable via the UI. We should not encourage otherwise.
That said I think we could let "menu-less" operators to show when "Developer Extras" is enabled in User Preference.
I believe I found a bug, there is no way to find the "Save As Image" from the Image Editor with the new search menu.
To have this noted somewhere: The remesh operators in sculpt mode ({nav Ctrl+R}, {nav Ctrl + Alt + R}) also don't show up in the search menu. I guess there's no menu entry.
We'll probably find more such cases, so maybe we should have a place to list and address them?
Added subscriber: @Vyach
Tested.
Icons — good. The allow better reading strings.
Menu tips — bad. IMO they shoul appear on mouse over. May be just special mark, or hover on icon. Now they just add visual noise.
Also sometimes I am searching 1st word but looking for second word in the list. So excess of words just confuse me.
When this option activated, search stop to show custom operators, that not in menus. Important!
I suggest this
Keyword on the first place, bright, aligned. Additional info dimmed, when unselected.
Also It can be aligned/ordered to right with «→»
Rule: only one hotkey of the lowest (closest to operator) level should be shown.
Even like this. Path is still dimmed a bit: brighter than other strings, darker than selected operator name.
Added subscriber: @aaolson817
What happens if an operator is present in the UI, but not in a menu?
Added subscriber: @satishgoda1
@Imaginer can you give examples of these which would make sense to be included in a search?
This has been resolved, I've added items to menus that previously weren't in any menu.
@ideasman42 Can you please add the "missing" Shade Smooth/Flat in one of the sculpt mode's menus?
The thing is, those operators are accessible and do work in sculpt mode too, but they were never in the menus, so the only way to access them was via the search (F3) function.
Now, with this new search system enabled by default
debd8aab4athere will be no way to access those operators, since they are not in the menus.So it would be nice to finally add them to the sculpt menu, so they can become searchable again. Not to mention that it helps with discoverabilty.
Added subscriber: @dr.sybren
@ideasman42 I'm mostly thinking of addons here. Some Addons put operators in the
Nproperties panel and nowhere else, or they add buttons somewhere such as Development: Icon Viewer (header of the console). But there are a few operators in core blender that are scattered around the interface, but not in menus such as baking operators.(Rigify has operators that are, somewhere, that show up in the old search menu, but not the new one for example)
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 @dr.sybren don't even have a hotkey and can only be accessed by the search menu.
On a slightly different topic, I may have found a bug about search in general. It seems that some operators that are added by addons aren't included in either the old search menu or the new search menu (like Real Snow -> Add Snow, ANT Landscape -> Mesh Displace, Modifier Tools -> Delete All). Can anyone confirm this?
@TheRedWaxPolice I looked into adding these menu items however this doesn't work with sculpt undo, nor does it work with dyntopo.
Sculpt should have it's own operator to handle this.
@Imaginer Panels could be included in the search too, for add-ons that only expose tools in panels.
Further for 2.90, add-ons should be updated so their operators are exposed in the interface without having to know to search for them.
Sorry if this is off-topic, but was this design goal discussed somewhere previously in more detail? I think Blender becoming cluttered with small drop-downs or sub-menus is a concern if this becomes a reality. Maybe this is out of scope for this thread, so if there's another thread for this please point me to it.
The issue I have with a menu-based approach is that it makes too many assumptions about both user behavior and add-on design. The basic idea of being able to register search aliases for operator presets is great, but there are too many situations where a search aliases make for bad menu entries, and menu entries make for bad search aliases.
If we could tag menus as searchable/non-searchable, most of those issues would go away. Add-on developers could then use searchable menus that aren't exposed through the UI to register aliases without adding clutter, and tag their convenience menus and pie menus as non-searchable to limit the number of duplicate search entries.
Removed subscriber: @blenderrocket
How come the new Search already replaced Operator search in master? This was quite out of nowhere, and I think way too soon. There are now official Blender addons with operators that cannot be found with the search, like Corrective Shape Keys and Rigify.
I've been trying to politely contest the idea of "addons will just add every button to the UI and life will be happy" but I guess that didn't achieve anything, so to be more blunt: This is a terrible idea!! Blender will end up drowned in drop-down menus and buttons all over the place that nobody uses.
Or maybe addon developers will be adding their operators to invisible UI elements (I guess that would work?) which is not the end of the world but it's a pretty ugly solution if you ask me.
Please let this new search display operators even if they weren't added to a menu, making it more of an Everything Search. Now that would be powerful!
Added subscriber: @ZedDB
It was @ideasman42
debd8aab4aI too think this is a very terrible idea and will only lead to very bad UI practices.
I'm getting File Browser rework flashbacks from this again.
(The issues we lined out there still haven't been full fixed either...)
Multiple people outside and from the studio give feedback this this is not good but it still gets silently merged.
@Mets The commit says "Enabling "Developer Extras" exposes operator search in the Edit menu"
Ah, indeed! Good to know Operator Search still exists, even if extremely well hidden... Although pretty sure this will just result in a lot of non-developers having to enable Developer Extras to find the operators from the addons that they picked up from all over the internets... It's not the end of the world.
@Mets I don’t know what all these addons are without user interfaces, but they should add buttons and controls to the Blender UI. For developers the old search is available still as a developer extra.
Operators, that are not in menus become invisible in search results too.
That is why I don`t use this feature now.
I am sure, that menues shouldn
t include every operator. For example, this one call temporary popup menu, just for adding operator or two from it to quick favorites (because I cant do it right from search or do not have tool for QF-editing). So I need to call operator only once. And I believe, that there can be more operators, that shouldnt fill menus and can be used once a year, when you don`t even remember, where they should be in menu.And other operators, that usable only with hotkeys.
So search should be full, as it was.
By the way, thanks guys for making dimmed text. Now it looks more readable.
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.
Right, the issue isn't the fact that there exist addons with no UI, and to attempt to summarize what was discussed this morning in #blender-coders, the issues are that:
There are now Blender Python tutorials out there that are invalid. There are now templates in blender's text editor that are invalid. There are probably cases in the documentation that need to be updated to point out the existence of Operator Search and how it differs from Menu Search, for the sake of up-and-coming python developers, and users who intend to use addons that aren't actively being developed anymore.
These things didn't get a chance to get mentioned because the commit happened what felt like in the middle of the discussion. Even that would've been fine, if someone had said something along the lines of "Okay, it's in master now for testing, let us know how it goes." But without that invitation for feedback, right now it feels like it's case closed, and the feature is complete. What about Right Click->Add Shortcut? Is that still in the works? We don't know.
Assuming it's still being iterated on, Menu Search is looking to be a potentially great addition to Blender, especially for new users, but more communication before important commits, please! :)
It's worth noting that Menu Search doesn't play nicely with nameless menus or icon-only menu entries (mostly found in pie menus):
I'm not a fan of the duplicate results, either:
The fact that you can't set the active tool via search feels like an oversight, too.
On the plus side, I've found that orphaned menus (menus that are registered, but not added to the UI) are great for adding search aliases.
@ThatAsherGuy
I think that way:
For the first case, it should show Hotkey for Piemenu and bl_idname if there is no name.
In the second case, probably the best result will be most context and most stable.
So Mesh->… can be excluded first.
For other two variants {key Ctrl}{key E} is more universal for edit mode even if user in vertex-select mode.
So conditions:
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.
What do you think?
Added subscriber: @elfoglalt
While this is a great addition, I feel like the current implementation conflates multiple use cases into a single tool, that does not necessarily need to be a single tool (or needs configuration options). To me, it seems like the following use cases are mixed:
The conflicts I see are:
Fundamentally, the "find something in the UI" and "do the thing" should be somehow separated. This feature is focused on the finding aspect, while the previous operator search was more about the using aspect. Sadly I do not have a golden bullet solution that resolves these conflicts, but there are probably a few options worth considering:
Added subscriber: @DanPool
I'm strongly opposed to this feature. As this stands, an addon developer has to add their operators to a menu for it to show up in search. This will end up bloating the menus and making them incredibly cluttered. Think about it: addon developers can only prepend or append to existing menus, meaning all addon operators will be piled up at the beginning or end of menus meaning you will have to scroll well into the middle of the menu before you get to builtin operators. Or developers have to create their own menu, meaning the menu bar will become huge and unmanagable.
There needs to be a way to also show operators that don't exist in menus, or this is going to backfire in a huge way. OR there needs to be some way for addon developers to place their menu items anywhere they want.
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.
@DanPool
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
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_menuandWM_OT_call_menu_pieoperators. That property could then be checked inmenu_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.
Otherwise I would prefer manual filtering: core menues, addon panels, hidden operators, pies, quickfavorites…
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).
Added subscriber: @dupoxy
I believe since commit
c46dcdf887, 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:
{F8494728, size=full}
This comment was removed by @dupoxy
@WilliamReynish Yep it does works ... if you use the shortcut F3,
not if you use the menu Edit>Menu Search
2020-04-25 20-09-50.mp4
Added subscriber: @Alaska
@WilliamReynish 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.
Added subscribers: @lichtwerk, @ankitm
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:
{F8496296, size=full, alt="menu search context mockup"}
@ideasman42 I think I found some inconsistencies...
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.
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...
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...
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
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:
Operator Search]SPACE_VIEW3DcontextOperator Searchis accessible through the topbar [thus pollingSPACE_VIEW3Dcontext will fail if I launch my operator fromOperator Search]What is the intended way to do this now?
Operator Searchin the 3DViewMenu Searchand then look for my operator there?Operator Searchto Quick Favorites to be able to haveSPACE_VIEW3Dcontext?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 @dfelinto suggested:
Although I wouldn't even hide this functionality under Developer Extras, but that's me.
Added subscriber: @mgoszcz2
Added subscriber: @RC12
This comment was removed by @Vyach
Added subscriber: @1D_Inc
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.
@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 {key 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.
@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.
@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 dont need it. But may be someone?That's interesting) Thank you for response.
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 ({key 1}, {key 2}, {key 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. :)
Update, the edit menu can now access visible spaces:
b9bb752e0ePropose 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?
Update, committed context menu
82704ac3edAdded subscriber: @don.miguel
Hello! I updated the diff that was mentioned here earlier.
Here is the latest demo and updated diff: {https://developer.blender.org/D6813#187081}
Added subscriber: @Dalkoom
I can not find Scatter Object in the Menu Search.
@Dalkoom
Did you enable it?
Removed subscriber: @elfoglalt
Removed subscriber: @RC12
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.
@JulianEisel
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 {key 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:
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.
(I also think zebra striping would address the hotkey uncomfortableness #74157#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.
Added subscriber: @jeric_synergy
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.
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.
@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.
Thank you for explanation. It is very important issue, so we would like to know it for sure.
Removed subscriber: @Dalkoom
Added subscriber: @viadvena
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.
Added subscriber: @Raimund58
@viadvena
And what is this?
Fair enough.
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.
There is a fine line between "industry standards compatibility" and "mimic Maya", and, indeed, sometimes this line is broken very roughly.
It didn't changed much, it is more dark and more Maya/ISS.
F3 for searchbar is animators setup, modellers setup is spacebar.
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.
I told about this...
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:
b1b1be17541a650fdcb2530ccde9091a623c183fThis could be exposed to a menu, I'd need to look into it though.
We could have save/load preferences in the defaults menu, I don't have a strong opinion on this.
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.
You can still access the operator search if you want, it's an option for the operator that opens this popup.
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.
@ideasman42 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.
Added subscriber: @E.Meurat
Changed status from 'Confirmed' to: 'Resolved'
Split out remaining todo's into their own tasks as the majority of this proposal has been completed: #80422 (Proposal to highlight menus during menu search), #80423 (Proposal to show empty search results when the text field is empty).
Added subscriber: @AlexMcKonst-2
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
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.
@ideasman42 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.
May be in the same place as others Object -> Clean Up?
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.
Added subscriber: @alefor
Blender's own templates_py /operator_*.py files need this.
Added subscriber: @cessen
I'd like to second what @alefor above said:
The Python operator templates (such as operator_simple.py in the text editor's "Templates" menu ) should be updated to include the minimal code needed to make the operator accessible to the user.
Just defining an operator isn't useful if it can't be accessed, and that makes those templates a bit of an educational stumbling block now. It also makes them no longer nearly as useful as a starting point for just knocking out a custom operator quickly.