UI: support searching in menus #110855

Merged
Jacques Lucke merged 38 commits from JacquesLucke/blender:single-menu-search into main 2023-09-06 18:16:52 +02:00
Member

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 shows Type to search... when a menu is opened that supports search.

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 shows `Type to search...` when a menu is opened that supports search.
Jacques Lucke added 6 commits 2023-08-06 15:36:32 +02:00
Jacques Lucke added 3 commits 2023-08-06 16:09:43 +02:00
Jacques Lucke added this to the User Interface project 2023-08-06 16:53:47 +02:00
Jacques Lucke added 1 commit 2023-08-06 16:59:52 +02:00
Jacques Lucke added 1 commit 2023-08-06 17:04:43 +02:00
buildbot/vexp-code-patch-coordinator Build done. Details
5cf73930ec
allow searching recent file list
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR110855) 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.

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.
Author
Member

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.

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.
Contributor

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

> 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
First-time contributor

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.

изображение

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.

Sure, but doesn't it already have some?
изображение

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. ![изображение](/attachments/7d4efd3c-4934-45af-98f0-298e2c3ea6cc) > 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. Sure, but doesn't it already have some? ![изображение](/attachments/9ce122ee-4b53-43cf-8f1c-4abe62dbc0f4)
Contributor

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.

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.
Author
Member

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.

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.

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'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.

Looks like this does not apply to these menus, which, in my opinion, really could benefit from this feature.

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.

> 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. 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. > 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'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. > Looks like this does not apply to these menus, which, in my opinion, really could benefit from this feature. 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.
First-time contributor

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.

Not sure why custom aliases shouldn't work with a general search.

There are no customizable aliases system support in Blender yet. Also custom aliases is a concept which makes global search faster.

Many such shortcuts probably work out of the box already, especially with #110828.

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 that does make it a bit slower is that you still have to press enter.

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.

> > 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. > > Not sure why custom aliases shouldn't work with a general search. There are no customizable aliases system support in Blender yet. Also custom aliases is a concept which makes global search faster. > Many such shortcuts probably work out of the box already, especially with #110828. 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 that does make it a bit slower is that you still have to press enter. 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.
First-time contributor

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 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**
First-time contributor

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.

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.
Member

Love the idea! Thanks for working on this.

A few notes:

  • It should be consistent. It should apply to all menus. Small enums can still have accelerator keys, but better be consistent for large menus than hand-picking which ones to enable search for.
  • It should be optional. Using accelerator keys is a kind of workflow, which can be faster in some cases and heavily relies on muscle memory.

The preference could be in the Menus panel under Interface, perhaps a On Key Press menu with the options Start Search and Activate Underlined or similar?

image

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.

Love the idea! Thanks for working on this. A few notes: * It should be consistent. It should apply to all menus. Small enums can still have accelerator keys, but better be consistent for large menus than hand-picking which ones to enable search for. * It should be optional. Using accelerator keys is a kind of workflow, which can be faster in some cases and heavily relies on muscle memory. The preference could be in the `Menus` panel under `Interface`, perhaps a `On Key Press` menu with the options `Start Search` and `Activate Underlined` or similar? ![image](/attachments/576c2a26-8a1b-4c17-9e6c-5e68fbdd0255) 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.
Contributor

Love the idea! Thanks for working on this.

A few notes:

  • It should be consistent. It should apply to all menus. Small enums can still have accelerator keys, but better be consistent for large menus than hand-picking which ones to enable search for.
  • It should be optional. Using accelerator keys is a kind of workflow, which can be faster in some cases and heavily relies on muscle memory.

The preference could be in the Menus panel under Interface, perhaps a On Key Press menu with the options Start Search and Activate Underlined or similar?

image

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

> Love the idea! Thanks for working on this. > > A few notes: > * It should be consistent. It should apply to all menus. Small enums can still have accelerator keys, but better be consistent for large menus than hand-picking which ones to enable search for. > * It should be optional. Using accelerator keys is a kind of workflow, which can be faster in some cases and heavily relies on muscle memory. > > The preference could be in the `Menus` panel under `Interface`, perhaps a `On Key Press` menu with the options `Start Search` and `Activate Underlined` or similar? > > ![image](/attachments/576c2a26-8a1b-4c17-9e6c-5e68fbdd0255) > > 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
Jacques Lucke added 6 commits 2023-08-31 19:38:53 +02:00
Jacques Lucke added 1 commit 2023-08-31 19:45:22 +02:00
Jacques Lucke requested review from Pablo Vazquez 2023-08-31 19:46:10 +02:00
Jacques Lucke requested review from Julian Eisel 2023-08-31 19:46:10 +02:00
Jacques Lucke requested review from Hans Goudey 2023-08-31 19:46:11 +02:00
Hans Goudey approved these changes 2023-08-31 21:31:37 +02:00
Hans Goudey left a comment
Member

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.

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')
Member

The compositor can be changed now too.

The compositor can be changed now too.
JacquesLucke marked this conversation as resolved
Jacques Lucke added 2 commits 2023-09-01 10:03:57 +02:00
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR110855) when ready.
Member

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 Cube yields first Mesh > Cube, then Empty > Cube, as expected since Mesh is listed first I guess.
image

However, searching for sphere yields first Empty > Sphere, instead of the mesh.
image

Any idea why this happens?

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 `Cube` yields first `Mesh > Cube`, then `Empty > Cube`, as expected since Mesh is listed first I guess. ![image](/attachments/181ae6ef-fbaa-4fcd-9982-ad92b4ceb255) However, searching for `sphere` yields first `Empty > Sphere`, instead of the mesh. ![image](/attachments/e9acee9d-bd64-434f-9ef8-130a4032c8da) Any idea why this happens?
Author
Member

@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_impl for 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.

@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_impl` for 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.
Pablo Vazquez approved these changes 2023-09-01 12:03:19 +02:00
Julian Eisel requested changes 2023-09-01 19:19:46 +02:00
@ -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_default
bl_search_on_key_press = True
Member

It's more consistent to use bl_options to set some flags.

It's more consistent to use `bl_options` to set some flags.
JacquesLucke marked this conversation as resolved
@ -247,6 +249,11 @@ enum {
UI_BUT_OVERRIDDEN = 1u << 31u,
};
enum class UIButFlag2 {
Member

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 typing UI_BUT and look at the auto-complete results when looking for a flag.

If we want a different convention that should be done separately.

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 typing `UI_BUT` and look at the auto-complete results when looking for a flag. If we want a different convention that should be done separately.
JacquesLucke marked this conversation as resolved
@ -248,2 +250,4 @@
};
enum class UIButFlag2 {
ACTIVATE_ON_INIT_SKIP_SELECT = 1 << 0,
Member

This could use some documentation. What is "on init"? What is "select"? And what is this used for?

This could use some documentation. What is "on init"? What is "select"? And what is this used for?
JacquesLucke marked this conversation as resolved
@ -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);
Member

Would make single_menu_idname optional (with a default value).

Would make `single_menu_idname` optional (with a default value).
JacquesLucke marked this conversation as resolved
@ -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();
Member

Would extract this stuff into a function, there's too much complexity and scrolling here already.

Would extract this stuff into a function, there's too much complexity and scrolling here already.
JacquesLucke marked this conversation as resolved
@ -1879,0 +1903,4 @@
static void WM_OT_search_single_menu(wmOperatorType *ot)
{
ot->name = "Search Single Menu";
ot->idname = __func__;
Member

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.

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.
JacquesLucke marked this conversation as resolved
First-time contributor

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.

image
image

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. ![image](/attachments/66097abe-008b-4b5f-9664-052674f7f5af) ![image](/attachments/66e27782-ab0b-46ad-8173-7e4f337ef9f4)
Jacques Lucke added 7 commits 2023-09-01 20:06:04 +02:00
Jacques Lucke requested review from Julian Eisel 2023-09-01 20:09:58 +02:00
Author
Member

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.

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.
Contributor

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.

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.

> 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. 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.
Jacques Lucke added 1 commit 2023-09-04 14:55:46 +02:00
Member

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.

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.
Jacques Lucke added 4 commits 2023-09-06 10:10:17 +02:00
Member

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:

ED_workspace_status_text(C, TIP_("Type to search..."));

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:

Type to search...

What do you think?

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: ``` ED_workspace_status_text(C, TIP_("Type to search...")); ``` 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: ![Type to search...](/attachments/2f73f076-0475-4910-a195-3fe0083d2150) What do you think?
Member

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.

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.
Jacques Lucke added 2 commits 2023-09-06 17:02:24 +02:00
Jacques Lucke added 1 commit 2023-09-06 17:06:42 +02:00
Jacques Lucke added 1 commit 2023-09-06 17:46:19 +02:00
Hans Goudey approved these changes 2023-09-06 17:57:10 +02:00
Hans Goudey reviewed 2023-09-06 17:58:09 +02:00
@ -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);
Member

Either add a check for MenuTypeFlag::SearchOnKeyPress here or add a comment that references it.

Either add a check for `MenuTypeFlag::SearchOnKeyPress` here or add a comment that references it.
JacquesLucke marked this conversation as resolved
Jacques Lucke added 1 commit 2023-09-06 18:00:27 +02:00
Julian Eisel approved these changes 2023-09-06 18:06:08 +02:00
@ -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,
Member

Maybe call this ..._NO_SELECT (picky)?

Maybe call this `..._NO_SELECT` (picky)?
JacquesLucke marked this conversation as resolved
Jacques Lucke added 1 commit 2023-09-06 18:13:25 +02:00
Jacques Lucke merged commit 7f9d51853c into main 2023-09-06 18:16:52 +02:00
Jacques Lucke deleted branch single-menu-search 2023-09-06 18:16:54 +02:00
First-time contributor

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

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 - 24fe81e602a8) 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
Member

@odil24 looks like there's a falsely placed bl_options = {'UNDO'} in a menu class (menus didn't use bl_options until now, and UNDO is a flag for operators). You can just remove that if so.
The second error seems unrelated, but hard to tell with this little info.

@odil24 looks like there's a falsely placed `bl_options = {'UNDO'}` in a menu class (menus didn't use `bl_options` until now, and `UNDO` is a flag for operators). You can just remove that if so. The second error seems unrelated, but hard to tell with this little info.
First-time contributor

@odil24 looks like there's a falsely placed bl_options = {'UNDO'} in a menu class (menus didn't use bl_options until now, and UNDO is 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:

> @odil24 looks like there's a falsely placed `bl_options = {'UNDO'}` in a menu class (menus didn't use `bl_options` until now, and `UNDO` is 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:
Member

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.

> 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](https://projects.blender.org/blender/blender/milestone/7) or at least when we are closer to it.
First-time contributor

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 :)

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 :)
Member

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 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.
First-time contributor

I have an idea for a "best of both worlds" approach.
Add the On Key Press dropdown 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 the Type to search indicator, since in this case the user knows they can search in any menu.
  • Mixed (default): Uses search on menus that have nesting in them, showing Type to search to indicate it, otherwise falls back to accelerator keys.
  • Accelerator keys: Always uses accelerator keys, could bring back Search for specific add menus like nodes and modifiers.
I have an idea for a "best of both worlds" approach. Add the `On Key Press` dropdown 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 the `Type to search` indicator, since in this case the user knows they can search in any menu. - `Mixed` (default): Uses search on menus that have nesting in them, showing `Type to search` to indicate it, otherwise falls back to accelerator keys. - `Accelerator keys`: Always uses accelerator keys, could bring back `Search` for specific add menus like nodes and modifiers.
First-time contributor

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''

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''
First-time contributor

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.

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.
First-time contributor

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

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
First-time contributor

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 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
First-time contributor

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.

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.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#110855
No description provided.