2023-10-10 User Interface Meeting

User Interface Module Meeting

Regular User Interface module meeting for planning and coordination.
Next meeting at the Conference


  • Pablo Vazquez
  • Hans Goudey
  • Julien Kaspar
  • Julian Eisel
  • Jacques Lucke
  • Harley Acheson

Merged Since Last Meeting

4.0 issues

High Priority Bugs

4.0 → 4.1 Retargeting

Near-Term 4.1 Targets



PLEASE make this an option :slight_smile: Personally I’ve never used those accelerator keys, so I really liked the change you did just a few weeks ago that I could just map the menu to Tab and just start typing to search like in any other node based program. Having to also press space is just an unnessecary annoyance.
And tbh I really think you should add the “search” box back there, not that I need it, but I don’t think newcomers do know at all that you can search those menus, so an indiator like that would be very useful for them.


@Gurra - Hey, I’m not discounting your opinion at all, but just want to mention that more has changed here than might be initially noticed. With this “spacebar to search” change we actually greatly expand the number of menus that can be searched from a small number of curated menus to basically every single dropdown and context menu. You can now even search things like your “Open Recent” list.

We were finding it difficult finding a way to communicate that just some menus were searchable like that. And sometimes you could have one that is searchable right next to one that was not. And the type to search process didn’t work correctly for languages that use an Input Method Editor like Chinese, Japanese, and Korean.


I want to add some information and points of view here:

  1. it’s not evident for users to know hitting space will bring up search.
  2. we used to have ability to “assign shortcut to search”, this function is removed due to redundancy as people can directly “type to search”. In both ways, just a single shortcut actually brings up the search. Compared to previous solutions, “spacebar search” is slower because we have to bring up the menu first.

Personally, I hope to get “assign shortcut to search” function back. It’s faster than “Shift+A, + spacebar”, and customizable as people may not want to rely on “shift+A”. Of course, it comes to an UI issue since we no longer have rows of “search”.


Hello. I was experiencing 4.0 beta and found this issue and signed up to comment. This patch may be intended to create a universal interface, but this change has made it very difficult to use the menu that originally had a search window. (such as node editor) I usually accessed the search window by clicking search button on shift+A, or pressing ‘s’ on shift+A. But in 4.0 beta, this all became impossible. I’d appreciate it if you could make this option available for previous versions of users. Thank you.


Please make this an option, having to press spacebar every time is like having a small rock in your shoe. Or at least a way to assign a shortcut to the search box directly. Thanks!


The new search by pressing space is just the worst of both worlds and I cant believe the old behavior was removed when it was just perfect!

The new one is super slow to use and it does not matches any other industry standard software, whereas the old behavior can be found in most industrial software’s and is super intuitive to use if you come from any other industrial standard software.

Also the add menus looks super cluttered and unreadable now again with the acceleration keys. Again, this is just the worst of both worlds.

The old behavior where you just type to add object/nodes was perfect! We already had a good solution/comprise on this issue. Please, add it back

Also it feels super rushed to add it to 4.0 beta, most people have already got adjusted to the old behavior, all videos and tutorials so far is using the old behavior, it feels like this needs more time in order to clearly communicate to the user. Its going to create a lot of confusion and disappointment when 4.0 is launched.


Agreed 110%

This was easily one of my favourite new features and I hope it comes back. Building node trees (no matter if in GN, Shader Editor, Compositor, …) suddenly just felt natural as in any other node based tool.


Super agree on this! Feelt so nice that you could make it worked like any other industry standard software for once! This was legitimately my number one most anticipated change for 4.0 :frowning:

1 Like

So you made menus searchable directly, then removed this feature for some reason, because there are some languages in the world that doesn’t fit it… ok. Terrible decision but whatever.

AND, when reverting a change, instead of keeping old shortcut for search, which was S, you changed it to Spacebar, animation shortcut nonetheless, and removed search panel in add menus. Why? What is the reason you ask users to relearn a shortcut they knew for ages? What does this change bring to us expect worse UX?

You congratulate yourselves about how better this version is to the previous one (it isn’t), but disregard how worse it is to the one before that, one before and in 3.6.

Abysmal change. One that could’ve been avoided if developers start taking user feedback into account and don’t isolate themselves in forums, where they can ignore every user opinion and scream NO FEATURE REQUESTS.

Is there even a way to revert this shortcut back to S? Maybe I can fix what you broke.


I am currently teaching Blender to a class. They learned that you press S to search in menus. And in one month I have to teach them that now it’s Spacebar and they have to change their muscle memory. Why?

Truly worst of both worlds. We lost both ability to search directly, and also old behavior we were used to.


Could this small tweak to make the placement of global transform settings consistent, be done before the 4.0 release?

A friendly reminder, that this forum is not the right place for feature requests. See the forum rules in the header.

Am I the only one that thinks that starting search with the space bar is a good thing?

I seem to remember that not too long ago, people weren’t happy that adding search to menus would remove accelerator keys. And now there’s a solution that has the best of both worlds, but requires one (1) extra key press, and people hate it?

Furthermore it allows all menus to be searchable, not just random ones. I imagine it would be very frustrating to learn a system where only some menus are searchable, and you just have to learn which ones.

That, and it lets you see commonly searched items before you start typing, something not possible with the previous system, and a feature that I think personally would make it much faster than before.

The outcry here seems so misplaced…


Yes there were some cries about accelerator keys being removed for Add Menus, but the step was right one. It followed industry standard and was widely anticipated and accepted.

Now what we have is:

  • People who wanted old way back don’t get it, they have to relearn a shortcut and change muscle memory.
  • People who wanted new way didn’t get it, have to relearn a shortcut and change muscle memory.

This is not the best, but worst of both worlds. Nobody gets what they want. And this is because UI/UX team got obsessed with fact that Add Menus were different from other ones. Ok, so what? Add menus serve EXTREMELY different purpose then other menus. They’re called more often. It’s ok if they’re different. Chasing consistency gave us worse UX possible in the situation.

But anyway, if they wanted accelerator keys back, why not keep search shortcut to S? or keep the search field at the top? All this change does is free S to be accelerator key. Just one key, and we have to change muscle memory for that.

Blender isn’t nobodys pet project and some people should stop treating it as such. Great amount of people use it, depend on it, and have workflows defined in it. Changing shortcut for something as basic and widely used as Search shouldn’t be acceptable, at least without user feedback. And if you do that, at least follow the Blenders principles and gave us the ability to change the shortcut in our configs.


I’m sorry, I’m really not seeing the issue here? Is the problem just that they’ve changed the shortcut from S to space-bar?

Could you not just change it back in the keymap preferences?

You can’t at the moment. It’s also quite tragic that we lost ability to search directly without pressing one more key, but I wouldn’t mind if at least we had old shortcut I’m used to. Now I have neither of those.

If the goal really is to satisfy both sides of the debate, just introduce preference - Do you want accelerator keys or direct search. If you get used to one of those you’re not gonna use other way anyway.

Making both sides equally unhappy isn’t quite the solution to issue people don’t agree on.


My two cents. I think a global search is vastly superior to accelerator keys. They don’t give you access to all items and they’re randomly assigned. Let’s drop the habit and realize we have a better solution now.
I’d also choose “immediate search” over accelerator keys any day. Hitting spacebar seems like such an unnecessary step. I’d also change the “add” menu shortcut to tab, like in most node-based software. This way you can directly search for nodes by hitting tab, no extra steps.


While I do think it seems like a nice little addition to be able to search in every single menu I haven’t really ever felt a need for it ever and will probably never even remember to use it anyways when it’s implemented, while searching in the add menus in node editors I do constantly all the time almost hundreds times ever day, so having to press that space button before I search feels like a very unnecessary extra step. So I (and many other it seems) very much seem to prefer not to have to press space before searching.
And I guess some people do want the accelerator keys still, so I really think you should consider making this an option in the preferences :slight_smile:

Oh and while on the topic, not sure how the search works, but when I search for for example “Named attribute” it always picks “Store named attribute” on top, not sure why it does this but it really should have “Named attribute” on top.
Also nested searching, ie if I search for “multiply” I should be able to get a Math node set to Multiply. You already have this in the drag-to-search, so please add this to the regular search as well :slight_smile:


We used to have a row in the add menu to search, it is removed because we could type to search. and with recent change, it causes some huge regressions:

  1. New users wont know that hit space bar will start to search. There are some warning, it’s known to be very unobvious.
  2. In the past you can assign shortcut to “directly search”. Recently we lost that function because we can directly search.
    In conclusion, “spacebar search” per se is not making any improvement compared to 3.6 and before, it is even worse in UI and UX, because of changes made for the reason of “type to search”.