Keymaps feedback


See here for the plans:

Right now it’s behaving identical to 2.7x, but we want to improve it.


Is it Technical possible at the moment without hazards to implement a:
“to the ground” function,
like in UE4?


I second this. Could we add box selection with click and drag for all editors?


One question. I just tried to test quick menus feature and menu items that was added in Object mode disappears in sculpt and edit mode. Shouldn’t this menu be consistent across the modes?

Also would be cool to have ability to add quick menu items from search results (spacebar search)

And quick menu had convenient “1,2,3…” keymap and now its gone forever? (UPD* its working with execute commands but not working with toggles)

P.S. Quick favorites menu is awesome


Outliner keymap suggestion:

#1 If you press an outliner eye with CTRL you will solo this object, but when you press it again to reverse, it’s doing nothing. Maybe it should behave like a toggle instead?


#2 How about to use CTRL+SHIFT+CLICK to quickly select list of objects in the outliner. That way we continue to use blender logic for the shortest path selection during the modeling process and use it in the outliner. So the users should get it pretty quick. For now to do the similar task we need to select objects with box selection or just click it one by one, then right click and choose “select” in the drop-down.


Most of the buttons are hidden in nested menus anyway, the user will think blender is just not as complete.


Hey guys, why not map ESC to either cursor or select tool?
that way we could set shortcuts to the rest of the tools and still not get stuck.


ESC cancels renders, bakes, and other jobs. We don’t want those to be interrupted when switching tools.


That’s intentional, so you can create a different menu per mode. The builtin context menu is also different per mode.


Easy make a cancell stack, the first thing to be cancelled is the active tool then any background job


It could be done by making shortcut priorities, if a shortcut has no effect it jumps to the next mapped to the same key.
Cursor and select would have the highest priority, if its already select, it jumps to the next operator mapped to esc, therefore, cancell anything.

I dont know how much work it would take, but I guess, its just a matter of adding a few extra internal states.


Overloading keys like that rarely goes well, it causes too much confusion.


well, but there must be a solution, one of the most anoying things in the current tool system is having to switch from tool to tool every time you want to select an object.


Left click select has W key for this. There could be a key in right click select too, not sure which one.


My first though was to use the number row to assign to each tool just like hotbars in FPS games, it’s generally a quite intuitive and agile approach but the numbers 123 are assigned to select vert\edge\face in edit mode.
The collections hidding and unhidding could be done by holding shift or alt+shift


We could assing number row 4 to select tool and number row 5 to cursor tool, its near to W and E and is fast to reach, just 30-45°, rotated in the hand pivot relative to esc.



I detect a bug with the keyboard but I do not know how to replicate it. I think it is generated by Poly Build, after using it, the right and left mouse button perform the same action on all tools, when normally with “right click select” the right button selects or moves if you drag the pointer. The selection continues to work, but the drag has been completely lost.
I am testing today’s version and although it has been fixed momentarily, now I can not get the usual interaction.


For the “select linked mesh” function to be assigned to double click on that mesh, curve, etc.
It can stay mapped to “L” at the same time but double-clicking on the needed element is really intuitive and fast.

And it can complement the branch of mouse selection behavior started with deselect with a click on empty space.

To continue this idea:
We don’t have any action assigned to double click on the object in the “object mode” right? What if we use it for select all objects in a group? So it will extend this logic of double-clicking for selecting “the whole” element.

What do you think guys, could it work?


I would hesitate to suggest double anything as a keybind.
It’s just horrendously unreliable, both in getting the timing right in the first place, and in it being dependant on the speed at which the application is running.


See how it could be done. :wink: