UI: support searching in menus #110855
No reviewers
Pablo Vazquez
Hans Goudey
Julian Eisel
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
20 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#110855
Loading…
Reference in New Issue
No description provided.
Delete Branch "JacquesLucke/blender:single-menu-search"
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?
The basic idea is very simple. Whenever a supported menu is open, one can just start typing and this opens a search that contains all the (nested) menu entries.
The main downside is that this collides with accelerator keys. Those are the underlined characters in each menu. For now, we just enable this new searching behavior in a few selected menus: Node Add Menu, View3D Add Menu, Modifier Add Menu.
This new functionality can be enabled for a menu by setting
bl_options = {'SEARCH_ON_KEY_PRESS'}to true in the menu type. The status bar showsType to search...when a menu is opened that supports search.@blender-bot package
Package build started. Download here when ready.
You don't need to open a separate search window, it's weird. Looks like almost the same as using F3 search.
Check how native menus work in macOS or Windows. There's some kind of incremental search. When the menu is open, you can start typing and the first matching item will simply be highlighted. If you repeat a keystroke (or sequence) after a short pause, the next matching item is highlighted. Something like this.
The user remains in the same menu as initially, the menu does not change, the user can see where the desired item is located. The behavior corresponds to what the user is used to in other programs.
Staying in the same popup is significantly harder in Blender currently unfortunately, but would indeed be better. Just not worth spending the time on implementing that if we are not sure yet what behavior we want.
Remaining on the same menu and not being able to search all submenus would make this feature rather useless to me unfortunately. My main goal is to use it for the node add menu. Staying only at the top level would make using the search way too slow.
Can't you just keep search menu that pops up with S when adding nodes, only you can just start typing right away instead of pressing S? that menu is much better than this F3 one, it's quite confusing when that large menu pops up
In my opinion such a concept has flaws in too longer string input or much more scrolling to reach the desired result in comparison to underscores. That was the reason of a PGP approach which allow custom aliases in aliases-related systems.
Sure, but doesn't it already have some?
Looks like this does not apply to these menus, which, in my opinion, really could benefit from this feature. I guess this is because these are not supported in search to begin with.
If supporting these menus is not feasible I think access keys should be enabled for these.
Not sure why custom aliases shouldn't work with a general search. Many such shortcuts probably work out of the box already, especially with #110828. The main thing that does make it a bit slower is that you still have to press enter.
That's what I'm doing for the most part. I'm not sure whether the menu search aspect is strictly necessary. It does feel useful sometimes when there are many submenus. Might just be something that takes some getting used to, not sure.
Don't see a fundamental reason for why those can't be support. Might just be a little bit more difficult. I agree that menus that don't have the search should keep accelerator keys.
There are no customizable aliases system support in Blender yet. Also custom aliases is a concept which makes global search faster.
It has nothing to do with heavy alternating which is inherent to menu items using, when new item is used each time.
The main thing is that underscores is much faster input method in general, since is direct - its input length is defined by menu depth, so it is hard to find a practical reason for its replacement with local search which assumes longer string input and lots of scrolling during heavy alternation.
For the limited cases when it could be beneficial (like adding nodes) a search menu has already been added.
Therefore, there is no practical problem such a PR is supposed to solve.
Blender is getting more and more node-based so it's really important to have a quick way to access the search.
While working with shader-, geo-, or compositing-nodes the user typically uses the search to add nodes hundreds of times, therefore any additional clicks quickly add up.
At the moment Blender has the most cumbersome way to access the search functionality compared to other cg-software, it is the only software that requires 3 buttons/clicks while all other packages i could come up with only require a single button or click:
Houdini: TAB
Nuke: TAB
Substance Designer: TAB
Maya: TAB
Unreal: RMB
Gaea: TAB
C4D: c
Embergen: RMB
Blender: SHIFT + a -> s
Blender isn't getting more and more nodebased, it always has been, as always nodes represents different local workflows from the very beginning.
Also not sure how such a local task as adding nodes is related to all menues across application.
Love the idea! Thanks for working on this.
A few notes:
The preference could be in the
Menuspanel underInterface, perhaps aOn Key Pressmenu with the optionsStart SearchandActivate Underlinedor similar?I think we all agree keeping the menu open and highlight/open menus as we type would be ideal, but that's something that can be done later.
I don't understand why remove accelerator keys for menus where search isn't needed. U - U for example is very handy UV Unwrap shortcut in Edit Mode. I use those keys very often, just change that for add menus
It takes few minutes to get used to, but this works well in my tests. Of course it's easy to imagine some UX improvements on top of this, but I think getting the basic behavior working is worth it now. The add menu looks so clean now too, it's surprising how much of a difference that makes.
The code looks straightforward too, at least I can't see anywhere I would have done things differently.
@ -236,4 +236,3 @@layout.separator()layout.menu_contents("NODE_MT_geometry_node_add_all")elif snode.tree_type == 'CompositorNodeTree':props = layout.operator("node.add_search", text="Search...", icon='VIEWZOOM')The compositor can be changed now too.
@blender-bot package
Package build started. Download here when ready.
Love it! Tested adding meshes and it's so much faster.
I'm trying to figure out what's the sorting that's used. Perhaps it has to do with giving weights to results and it's part of a separate patch.
Searching for
Cubeyields firstMesh > Cube, thenEmpty > Cube, as expected since Mesh is listed first I guess.However, searching for
sphereyields firstEmpty > Sphere, instead of the mesh.Any idea why this happens?
@pablovazquez This is most likely caused by a heuristic that sorts shorter search items to the top, because those are usually better. See
StringSearchBase::query_implfor other heuristics.I think this is generally fine, and the real solution here is to remember recent searches (#110828) instead of trying to tune the weights manually.
@ -223,6 +223,7 @@ class NODE_MT_add(bpy.types.Menu):bl_space_type = 'NODE_EDITOR'bl_label = "Add"bl_translation_context = i18n_contexts.operator_defaultbl_search_on_key_press = TrueIt's more consistent to use
bl_optionsto set some flags.@ -247,6 +249,11 @@ enum {UI_BUT_OVERRIDDEN = 1u << 31u,};enum class UIButFlag2 {Prefer to keep this consistent with the existing button flags and using a bare enum with a similar prefix, say
UI_BUT2_. Otherwise it make it hard to find these when you're used to the current convention, e.g. you'd typically start by typingUI_BUTand look at the auto-complete results when looking for a flag.If we want a different convention that should be done separately.
@ -248,2 +250,4 @@};enum class UIButFlag2 {ACTIVATE_ON_INIT_SKIP_SELECT = 1 << 0,This could use some documentation. What is "on init"? What is "select"? And what is this used for?
@ -2405,3 +2413,3 @@void uiTemplateOperatorSearch(uiLayout *layout);void UI_but_func_menu_search(uiBut *but);void UI_but_func_menu_search(uiBut *but, const char *single_menu_idname);Would make
single_menu_idnameoptional (with a default value).@ -10714,0 +10722,4 @@if (menu->menu_idname[0]) {MenuType *mt = WM_menutype_find(menu->menu_idname, false);if (mt->search_on_key_press) {uiAfterFunc *after = ui_afterfunc_new();Would extract this stuff into a function, there's too much complexity and scrolling here already.
@ -1879,0 +1903,4 @@static void WM_OT_search_single_menu(wmOperatorType *ot){ot->name = "Search Single Menu";ot->idname = __func__;Not sure if I noted this before, but I'm unsure about using
__func__for the operator idname. This breaks BPY compatibility when renaming a function (!) and it uses an "implementation-defined format" in C++ (unlike in C). See https://stackoverflow.com/questions/4384765/whats-the-difference-between-pretty-function-function-func or https://en.cppreference.com/w/cpp/preprocessor/replace#Predefined_macros.While I really like the change, I feel like when searching for nodes it feels way noisier and takes more time to find what you want compared to the old search. I don't personally see any benefit for the node menu path since it's useless when you already know the node name.
It's always faster to add a node through searching the node name rather than finding it in the menus, so if you already know the name of the node, it's not very useful. The add node menu is mostly for discovering nodes when you dont know the name; the menu is just slower than searching for the node and therefore in my opinion there is no benefit to show the menu path.
I think it's worth showing the menu path for now as it adds information that might be somewhat difficult to find otherwise. Maybe it will be more useful for assets libraries when they don't have to use overly verbose names for every node group.
If showing the menu path really makes you slower, even after getting used to it, we could consider a redesign. Either the menu path could be removed, or we can find a better way to present the data so that e.g. the menu path is on the right so that the actual node names are aligned.
Currently, I think that this new search won't make you slower in the long run. Especially, when we remember recent searches (#110828). For commonly used nodes, I think you will be able to use the search without looking at it at all after getting used to it.
This would be ideal. This does make things slower, and I know that will not change because I constantly use F3 and it still slows me down. Reason is you never know where to expect item name. With old menu they're aligned always on the left, so your eyes go there, but with this one they can be anywhere, and constantly go from left to right and you have to catch up.
The code looks fine now on a quick look (TM :) ). But I would like to look at the design again together with @pablovazquez tomorrow. There are some things on the UI/UX design level that I need to make up my mind about still, shouldn't take long.
Just had a discussion about this with Julian, we have a few notes.
Accelerator Keys
The "no accelerator" flag should trickle down to sub-menus. It's a bit confusing at the moment that you can only type to search when the mouse is over the first root menu.
Indicators
Since this feature is not available in all menus, we need to communicate when it's possible to start typing to search.
One place could be the status bar.
Something like:
At the moment the status bar even shows wrong info when a menu is open, it's stuck in whatever options were there before the menu open.
Another possible indicator is having it part of the menut itself:
What do you think?
Adding a message in the status bar sounds good to me. I think it would be nice to keep it out of the menu itself, since as people get used to this it just takes up space, and it also feels a bit wrong when the search opens a new menu.
@ -815,6 +820,8 @@ uiPopupBlockHandle *ui_popup_block_create(bContext *C,void ui_popup_block_free(bContext *C, uiPopupBlockHandle *handle){ED_workspace_status_text(C, nullptr);Either add a check for
MenuTypeFlag::SearchOnKeyPresshere or add a comment that references it.@ -250,0 +255,4 @@* box as soon as a popup opens. Usually, the text in the search box is selected by default.* However, sometimes this behavior is not desired, so it can be disabled with this flag.*/UI_BUT2_ACTIVATE_ON_INIT_SKIP_SELECT = 1 << 0,Maybe call this
..._NO_SELECT(picky)?Hi @JacquesLucke
I have tried to porting LuxCore Render addon (I'm part of dev of the addon) for Blender 4.0a (September 08, 02:12:54 -
24fe81e602) and have this kind of issue. This kind of issue has not been on Blender 3.6.1(3.6.2 and 3.6.3) but in 4.0a@odil24 looks like there's a falsely placed
bl_options = {'UNDO'}in a menu class (menus didn't usebl_optionsuntil now, andUNDOis a flag for operators). You can just remove that if so.The second error seems unrelated, but hard to tell with this little info.
Thank you. The problem has been fixed but Blender crash after this kind of error:
Please open a new issue, this thread is unrelated (and notifying 12 people on every message).
Also as a general advice, it's not recommended to update add-ons during the Alpha stage of development, since the API is prone to change and you'd end up re-doing work several times. Better wait until the Beta stage or at least when we are closer to it.
Yo, while you're at it it would be really nice to add that "deeper" search like we have in the drag-search, ie you can search inside the math node for example multiply, smooth maximum etc etc :)
I think this is a step backwards. First of all, the disappearance of the search menu results in the hiding of key functions, which is smart but not intuitive. Second, the underlined shortcut was almost the default standard for menus in modern interfaces, but now it's gone.
I got used to the underline shortcut keys and even gave up the interface in my native language and used English. But Blender is killing this feature and tradition.
I have an idea for a "best of both worlds" approach.
Add the
On Key Pressdropdown in preferences, and give it three options:Search: Starts a search in any menu (maybe for menus without nesting, it could do highlighting similar to searching in the property editor, but with autoselect, instead of completely changing the menu?). Does not show theType to searchindicator, since in this case the user knows they can search in any menu.Mixed(default): Uses search on menus that have nesting in them, showingType to searchto indicate it, otherwise falls back to accelerator keys.Accelerator keys: Always uses accelerator keys, could bring backSearchfor specific add menus like nodes and modifiers.The first letter of Chinese will force English to be entered, resulting in the need to press BackSpace to undo it a bit.Chinese ''yanse'', becomes English ''y'' + Chinese ''anse''
I accept the solution for nodes. Here it is perfect. I've been pressing 's' for weeks to quickly access the Search with a single click. However, the drawback for other areas is much more significant for me. For example, getting a standard object in the Layout/Modeling Workspace used to require just 4 keys: i.e. Shift-A (2 keys), 'M,' and 'C,' for the Cube. Now, I have to press Shift-A (2 keys), 'C,' and either 2 arrow keys down, or a second letter 'U' and 1 arrow key down and then still pressing Enter, or even click with the mouse, which I really don't want to do! So, currently, I'm pressing many more keys than before. It's also inconsistent that in Edit mode, when I press Shift-A, the accelerator keys are active.
Just a quick suggestion: why not keeping numeric accelerator keys?
I mean the ability to choose an entry by typing its numeric position in the menu (well, at least from 1st to 9th).
This way those who prefer keeping the muscle memory approach will still have the chance to use a 1/2 keys workflow.
Even when using this immediate search feature.
Can be the best from two worlds: quick memory operations (top row numbers in the keyboard), or full search, typing letters in the lower part of the keyboard
I want to add a suggestion for this. I like to search to be language independent. It would be great if it will search correctly even If I forgot to change language of keyboard input. Look how smart it is done in Gnome Shell: https://youtu.be/WoZkXihB2hc
I use accelerator keys all the time, so this slows down my workflow significantly. If other people prefer it, that's fine. It doesn't bother me if it's on by default, just as long as I have the option to disable it. It simply isn't helpful for me.
Searching is definitely faster when I'm working with uncommon operations, but it's already easily accessible. Having search activate automatically gets in the way more often than not. If I already know what I'm trying to add, it took at most three keystrokes in 3.6: open the menu > open a submenu > select an item. Now, it's entirely dependent on how many items have similar names to what I'm looking for.