Blender 2.8 Blender Keymap changes
Open, NormalPublic

Description

This is an ongoing topic, design is not final
Update: We recently added the ability to detect drag events separately from regular key-presses, so we now have the ability to use pie-menus as a secondary input method for keyboard events. For this reason, we are experimenting with reinstating the Tab key for mode switching, so that pressing Tab works as before. However, holding Tab while dragging enables a pie menu for mode-switching. This exact configuration is experimental, but committed for further testing in the Blender Studio. We may apply this approach to other hotkeys too later on.

In Blender 2.8, we want to make some changes to the default keymap. The goal is not to do a complete overhaul of the Blender keymap, but rather to identify specific problems and then solve them. Blender 2.8 will require some amount of relearning, so now is a good time to address some of the keymap issues we have.

Current State (testing)

For now this shows the new keymap for people who want to use 2.8

The list of changes which have been applied is maintained here: T55194

Previous State (Blender Version rBcfc4805455b)

lots of information is interesting, but content is not matching current Blender 2.8 state.

Issues

Specifically, we want to address these issues:

  • Mode selection is very inconsistent
    • Switching to some modes is not possible from certain modes
    • The hotkeys to change modes changes depending on the active mode
    • Tab to toggle Edit Mode is fundamentally in conflict with the fact that we have more than two modes
  • The laptop-oriented option ‘Emulate Numpad’ is not good
    • It makes switching between desktops and laptops a pain when they are not consistent
    • The row of number keys don’t spatially communicate the view directions, unlike the numpad numbers
    • It’s a pain for users to have to manually switch this setting depending on the keyboard they are using.
  • Space bar to switch active tools conflicts with the Operator Search feature
    • It’s inconsistent if it’s double tap space some places, and single tap space in others
    • It makes Operator search slower to access if you have to press space twice.
  • Number keys to switch layers no longer map well to 1-9 number row keys
    • We can now have an arbitrary number of collections, not just 20
    • Users can also have less than 20 collections, rendering the number keys useless in that case
    • Collections can be nested, so mapping to 1-9 will produce unexpected behaviour
  • We have many shortcuts for specific enum settings (eg period for 3D Cursor Pivot)
    • This makes it hard to learn all the shortcuts, because users have to remember many hotkeys for one feature
    • This makes our keymap very bloated, because one feature (eg pivot point) uses multiple keyboard keys
    • This means many useful features (eg orientation) cannot be quickly accessible from the keyboard

Changes

With the above problems in mind, here’s how we are thinking of changing the default keymap in Blender 2.8:

Switch Modes: Tab + Pie menu

We want to keep using the Tab key for mode switching, but make it more consistent and better suited to switch quickly to any mode. We do this by keeping the old tab-to-editmode behaviour, but also making it so you can hold Tab and drag to spawn a pie menu with all the modes available. Pie menus can be very quick to use, because you can simply flick using a gesture while holding Tab.

Switch Collections: Dash (-)

For Collection (layer) switching, we can no longer use the number keys as we did in the past, because of the fact that users can have an arbitrary amount of Collections, and because they can be nested.

However, we still want to enable a quick way to switch between them using a keyboard-centric workflow, like so:

Users can hit the dash key, which opens a menu of Collections under the mouse cursor. They can then simply click each Collection to set it to Local View, hiding all the other collections.

Also, these Collections are dynamically assigned a hotkey, which becomes active and visible when this menu is open. If Collections are nested, users can hit two number keys in a row to jump to nested collections.

Operator Search: Tilde or F3

This can make the Operator Search feature more consistent, so it’s always one keystroke away.

Switch Tools: Space

Makes switching the active tool very easy and accessible. It can become context sensitive to fit with the mode and editor.

Applications where a tool system is the only way to access functionality often bind these tools to keys.
Blender already has a fast, keyboard oriented workflow, which we don't want to drop at the expense of introducing a tool system.

On the other hand, a tool system does not have to be inefficient (if an add-on adds a useful tool to the toolbar, we should have a fast way to access it).

Using space as a modifier key allows the full set of keys to be used for tool access without conflicting with existing bindings.

Currently tools key bindings are set based on the keys used for immediate (non-tool) access.

Eventually we will auto-assign the other items in the menu.

This way pressing:

  • G grabs
  • Space-G sets the grab tool.

... same for scale, rotate .. etc.

This way experienced users who are familiar with Blender's shortcuts can keep the toolbar hidden and occasionally access them via keys they already know.

Arrow keys can also be used to navigate to a different tool - starting from the active tool.

Enable specific Sculpt & Paint Tools: Various direct keyboard shortcuts

To make Blender more consistent, we want to the number rows to behave consistently. For this reason, we would like to remove the number keys to switch tools in paint and sculpt mode. However, there will still be ways to use hotkeys for switching tools, just not the number row keys. In Paint & Sculpt modes, the hotkeys will be displayed in the toolbar. Users can also use the space bar to get a quick menu and change tools this way.

Viewpoint Switching: Numpad numbers & Tilde (~) Pie Menu

This makes it more consistent, so that the number keys work in a consistent way, both for laptops and desktops.

Switch Workspaces: Ctrl+Tab (next) & Ctrl+Shift+Tab (previous)

With Blender 2.8, we are introducing workspaces. We want to make switching between them easy. We want to make it work like switching browser tabs.

Pivot Point: Period (.) to cycle though them. Hold period (.) to display pie menu with all pivot options

This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the period key to cycle through pivot options, or they can hold down period to display a pie menu for quick switching.

Orientation: Comma (,) to cycle though them. Hold comma (,) to display pie menu with all orientation options

This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the comma key to cycle through orientation options, or they can hold down comma to display a pie menu for quick switching.

Here’s a more concise overview of the changes:

KeyChangeStatus
Edit ModeTabdone
ModeTab+dragdone
Sub-modes( Vert/Edge/Face)1, 2, 3done
SearchTIlde or F3done
Active Tool SwitchingSpacedone
Workspaces SwitchingCtrl+Tab & Ctrl+Shift+Tabdone
Pivot SwitchPeriod (.)
Orientation SwitchComma (,)
Viewpoint SwitchingNumpad Numbers & Tilde key (~) Pie menudone
Collections SwitchingDash (-)
Favourites MenuQdone
Context Sensitive MenuWdone
Current Blender Keymap Inconsistencies

Anton Atnoguzin mailed us with a list of inconsistencies in Blender's current keymap. Here's a list:

Current InconsistencySimilar ToFixStatus
Image EditorUnwrap: E3D View Unwrap (U)Udone
Mesh Edit ModeVertex Ungroup: NoneObject Mode Ungroup (Ctrl-Alt-G)Ctrl-Alt-Gdone
Select Mirror: NonePose Mode Select Mirror (Ctrl-Shift-M)Ctrl-Shift-Mdone
Lattice EditProportional Edit Connected: NoneProportional Edit Connected (Alt-O)Alt-Odevelopment needed
Flip Ctrl-FSwitch Direction (Armature) & Flip Quats (Pose) (Alt-F)Alt-Fdone
Pose ModeFlip Activate/Selected Bone: Shift-Ctrl-FSelect Mirror (Shift-Ctrl-M)Shift-Ctrl-Mdone
DopesheetSample Keyframes: Shift-OConflicts with Proportional Edit Profile (Shift-O)Shift-Alt-Odone
Mirror: Shift-MMirror: (Ctrl-M)Ctrl-Mdone
Graph EditorSample Keyframes: Shift-OConflicts with Proportional Edit Profile (Shift-O)Shift-Alt-Odone
Mirror: Shift-MMirror: (Ctrl-M)Ctrl-Mdone
Node EditorUngroup: Alt-GUngroup(Ctrl-Alt-G)Ctrl-Alt-Gdone
Animation ChannelsUngroup: Alt-GUngroup(Ctrl-Alt-G)Ctrl-Alt-Gdone
NLAAdd Meta-Strip: Shift-GAdd Meta Strip (Sequencer): (Ctrl-G)Ctrl-Gdone
Remove Meta Strips: Alt-GRemove Meta Strip (Sequencer): (Ctrl-Alt-G)Ctrl-Gdone
Particle ModeTools: NonePaint Tools (Various)Various
OutlinerAdd Driver: DAdd Driver (Ctrl-D)Ctrl-Ddone
Remove Driver: Alt-DAdd Driver (Ctrl-Alt-D)Ctrl-Alt-Ddone
Duplicate Object: NoneDuplicate Object (Shift-D)Shift-Ddevelopment needed
Duplicate Object Linked: NoneDuplicate Object Linked (Alt-D)Alt-Ddevelopment needed
Clip EditorCenter Current Frame Numpad Period (.)Center Current Frame (Numpad 0)Numpad 0done
SequencerUnMeta Strip Alt-GUngroup (Ctrl-Alt-G)Ctrl-Alt-Gdone
Mac Keymap

We want to improve support for Mac keyboards in two ways:

  • We want to globally support the Cmd key in addition to Ctrl
  • We want to support Backspace for Delete

Details

Type
Design

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Backspace doesn’t seem to be used for anything in the 3D View (except for edit mode for font objects). And it’s a nice, large key; easy to hit.

Ok, I guess Ctrl-Tab will do the job. But I really think tab drag was really close from something great :)

I want to remember that in a lot of laptops and almost all apple computers F3 is a really hidden hotkey because you need to press Fn and F3 to have access to F3. Nobody uses this F1-F12 shorcuts because it's a PITA. It's at least 10% of the potential users (20% in USA). Also that few people use F3 to search, it's a common shorcut for really expert users (coders mainly). The mayority of people uses Ctrl+letter (in windows the letter depend of the language of operating system in spain is B, for example).

I want to ask if developers have though in some way to make easy to access to search (actual option in edit menu is really hide). Like, for example, to put a searchbox inside new active tools toolbar with this behaviour

  • Press spacebar + press letter = Active tool shortcut
  • Press spacebar + release space + begin to write = searchbar

It's weird some actual behaviour and shortcuts of the activetools toolbar, like after press space you need to press other hotkey (Ctrl+B) to select one active tool. I don't that newbies will learn this type of behaviours and old user will configure their own hotkeys or only the menu.

@Alberto Velázquez (dcvertice), enough common shortcuts are using F-Keys (render for example).

We have AccentGrave as a easier to access key, on US/English layouts this is always available.

For non-US/English layouts we can support scan-codes, but this requires some development on each platform. It's done for Linux, macOS/win32 still need support added.

I don't think the need for development is a reason to avoid using the key, it may be only a few lines of code to change on each platform for all I know. It's just that nobody looked into it yet.


I want to ask if developers have though in some way to make easy to access to search (actual option in edit menu is really hide). Like, for example, to put a searchbox inside new active tools toolbar with this behaviour

  • Press spacebar + press letter = Active tool shortcut
  • Press spacebar + release space + begin to write = searchbar

    It's weird some actual behaviour and shortcuts of the activetools toolbar, like after press space you need to press other hotkey (Ctrl+B) to select one active tool. I don't that newbies will learn this type of behaviours and old user will configure their own hotkeys or only the menu.

From recent experience, drawing distinctions between subtle changes in behavior tends to be confusing & annoying. It also makes switching tools significantly worse.

I think that both F3 and the accent is an absolutely hidden shorcut for new users, never in my life I would think of using both of them not for search, but simply for any hotkey, since this is not an FPS that is where that hotkey makes sense. It's hard to think that any user will use taht shortcuts to find something.

When I started with blender 6-7 years ago after 10 years using 3dsmax, I had no idea how to use the program and it had thousand of commands. One of the things that made me take risks and made the program very easy was to find myself in the first few minutes of use, by coincidence, the searchbar in the space bar. Because it allowed me to have the full potential of the program with a simple hotkey. No matter how much you like it, all the hotkeys that are being tested hide this functionality, which is essential and of the greatest success that blender had.

I know other programs don't have it easily available or don't have it directly, but blender certainly makes it better to have it in a simple shortcut. And we only have to see Android, iOS, macOS and windows10 that put that functionality on the user's face with a search bar in the middle of the user's face. I have taught blender to a lot of co-workers and without a doubt the most used thing, especially in the first few weeks, was that ability to have that help on hand. My co-workers loved the whole "how do you do this in blender?" thing and just click on space and look for a term for it. Specially when you are a expert and you know that you need to learn hundreds of things an you don't want to learn hundreds of icons in the interface and search taht icons/buttons.

I don't think it's a problem to look for a solution like the one I'm saying about the toolbar when blender currently has similar behaviors when it comes to adding nodes. And other programs like Houdini have exactly that behavior. You can polish the idea but it seems functional and uncomplicated. It is a function that is explained in itself.

I was just messing around with the hotkey list and came across something interesting. Switching Tab key from Click to Press for Toggling into Edit Mode suddenly made it seem much 'Snappier'. Even Tab + Mouse-Drag for Mode Select Pie feels much more responsive. That micro lag/stutter that used to happen occasionally seems to be gone? Idk, maybe it's just me and some placebo. :)

I was trying this out because I've come to love the Tab: Toggle Edit Mode, Tab + Drag-Mouse: Mode Pie. (Without a doubt one of the best uses of a single key for multi-functionality.) And after I download tonight's build, I wanted to make changes to keep it the same way for myself. Was pleasantly surprised when I changed the key-press function and Tab just became a whole lot sexier! :D

Mockup

This breaks using accelerator keys to access tools, which is the main purpose of having it accessible from a key.


I was just messing around with the hotkey list and came across something interesting. Switching Tab key from Click to Press for Toggling into Edit Mode suddenly made it seem much 'Snappier'. Even Tab + Mouse-Drag for Mode Select Pie feels much more responsive. That micro lag/stutter that used to happen occasionally seems to be gone? Idk, maybe it's just me and some placebo. :)

I was trying this out because I've come to love the Tab: Toggle Edit Mode, Tab + Drag-Mouse: Mode Pie. (Without a doubt one of the best uses of a single key for multi-functionality.) And after I download tonight's build, I wanted to make changes to keep it the same way for myself. Was pleasantly surprised when I changed the key-press function and Tab just became a whole lot sexier! :D

How do you prevent the press event from being used before the drag event activates?

Looking over this task and there are some remaining things I'm unsure of.

We want to improve support for Mac keyboards in two ways:

  • We want to globally support the Cmd key in addition to Ctrl

Could we run a post process that duplicates all the key-bindings that use Ctrl?

  • We want to support Backspace for Delete

Why? We already have 'X' key for delete. Having 3 keys for the same thing seems excessive. (Especially if you multiply out all the combinations used with modifier keys)

How do you prevent the press event from being used before the drag event activates?

Hmmm. I was trying both ways out. Tab as Click or Press. Although it seemed snappier, there was a difference I couldn't really wrap my finger around. I think it's exactly what you mentioned Campbell. When I set Tab to Press instead of Click. Each time I 'Hold' the Tab key and Drag-Mouse for Pie Menu. It activated the Edit Mode Toggle as well. Seems this doesn't happen with the 'Click' method. So holding down Tab doesn't activate the Toggle Edit Mode command. And moving the mouse activates the pie menu without disturbing the current selected mode of the object. (But you already knew that. :D)

Guess that's the beauty of experimentation eh? Learn something new everyday. Thanks for clearing it up for me. Was a bit overly enthusiastic with my findings it seems. :D Still, looking forward to keeping Tab + Drag-Mouse for Mode Pie. (In my personal key config of course.) I just love it too much and it hasn't obstructed me in my workflow in anyway to justify binding a whole new key combo just for the pie. IMO, Ctrl + Tab can be used for something much more frequently used. Especially when Tab + Drag can do the Pie just fine. But that's just me. :)

Thanks man, have a good night. Also great work clearing up almost all those keymap inconsistencies. Didn't even notice until you started fixing them. Cheers.

Also +1. No to 'Backspace' as another delete. Just a waste of a key and completely pointless. Takes away the whole purpose of a 'Default Minimal Keymap'. I think 'X' for 'Workflow' and 'Delete' for 'Standard' is reasons enough.

Also +1. No to 'Backspace' as another delete. Just a waste of a key and completely pointless. Takes away the whole purpose of a 'Default Minimal Keymap'. I think 'X' for 'Workflow' and 'Delete' for 'Standard' is reasons enough.

Really? It might be only me, but every time before pressing "x" to delete something I keep pressing "Backspace" several times before getting used to "x" again. To me personally it's a mystery why on earth (I'm really exaggerating here) isn't "Ctl/Cmd+a" used to select all objects, like any other application (and every OS) does? But again it might be subjective, I just wished every new user had a luxury to find familiar key bindings like "Ctrl/Cmd+a" to select all, "Ctrl/Cmd+c" to copy, "Ctrl/Cmd+v" to paste, "Ctrl/Cmd+x" to cut, "Ctrl/Cmd+d" to duplicate/clone/link (in some combination with "Alt" and "Shift" keys), and ideally it should be possible to deselect by clicking on empty space in the viewport (complex selections can still be saved in a vertex group in between, so no need to worry about loosing it). It is no big deal to change keyboard shortcuts for experienced user, it is for a newbie who knows nothing about Blender keymap.

@Orustam Manapov (orustammanapov) I understand where you're coming from. Even for me, I still have to consciously remind myself to use the 'Blender' part of my brain to do certain things differently from the way my brain has been conditioned using other software for years. :) But at the same time, everything that's discussed in this task is about the 'Blender Keymap Changes'. So it will naturally follow the Blender hotkeys and how to simplify them but still keep them familiar enough for newer & older Blender users alike. They are also working on a more 'Industry Standard Hotkey Preset'. And that focuses on everything you said. Ctrl + A to Select All, Left-Click to Select, Click-Drag to Box Select, Etc.

So practically you can never have one hotkey preset that fits everyone. But don't be worried, because they are giving us the options to choose which works best for us. Even now, this Default (Minimal) Keymap is so users can have a foundational preset to build upon. Depending on their workflows & needs. Giving users the freedom to Add/Change/Remove what they like or don't like. But at the same time, like I mentioned before. There will be more Standard Presets for people who just want to Set-It, Forget-It and Get to Work with Minimal Modifications. :)

For example. If you find yourself out of habit pressing 'Backspace' everytime you want to delete something. By all means. You have the freedom to replace Delete/X with Backspace. That's the whole point of this Default 'Minimal' Keymap. They give us a good starting off point. We can customize it according to our Habits/Needs/Workflows. And that's always a good thing. --- I myself have changed many keys in the past few days and I'm still experimenting with other ideas. I could never do that with the old Blender Preset. It was too convoluted with keys that I didn't use or need. I didn't even know where to start, which ones to replace without affecting something else.

What's being discussed/debated here is about what keys to ship as 'Default' with this new 'Minimal' preset. But by no means does it mean you, the end-user is going to be blocked from customizing it to your needs. On the contrary, the whole purpose of this new preset is to 'Encourage' users to create their 'Own' Blender Keymap. --- With this Minimal Preset. I get to choose what works best for me. :)

Also I'm pretty sure they will make it easier to modify hotkeys with a more intuitive Hotkey Editor in the future. The current one does the job well, it's pretty accurate. But for a beginner it can be quite intimidating as you said.

Also +1. No to 'Backspace' as another delete. Just a waste of a key and completely pointless. Takes away the whole purpose of a 'Default Minimal Keymap'. I think 'X' for 'Workflow' and 'Delete' for 'Standard' is reasons enough.

Really? It might be only me, but every time before pressing "x" to delete something I keep pressing "Backspace" several times before getting used to "x" again. To me personally it's a mystery why on earth (I'm really exaggerating here) isn't "Ctl/Cmd+a" used to select all objects, like any other application (and every OS) does? But again it might be subjective, I just wished every new user had a luxury to find familiar key bindings like "Ctrl/Cmd+a" to select all, "Ctrl/Cmd+c" to copy, "Ctrl/Cmd+v" to paste, "Ctrl/Cmd+x" to cut, "Ctrl/Cmd+d" to duplicate/clone/link (in some combination with "Alt" and "Shift" keys), and ideally it should be possible to deselect by clicking on empty space in the viewport (complex selections can still be saved in a vertex group in between, so no need to worry about loosing it). It is no big deal to change keyboard shortcuts for experienced user, it is for a newbie who knows nothing about Blender keymap.

pressing Cntrl/Cmd + a is really less effective than simply "A" some people dont have the flexibility to stretch the hands on some keys fast or accureately, and for most frequently used commands like "select all" its better to not put muscular pressure, at least your finger joints will last longer...

And I will be honest, there is easy way to learn all the key shortcuts of blender really easy.

SLAP your hands on

"A" for toggle select is one of the best things Blender has, why splitting the action and adding "ALT+A" Also will there be another shortcut for creating a custom manipulator orientation? previously "CTRL+ALT+Spacebar" another of Blender strengths.

Don't know if it has already been mentioned here, but in the Python console, ctrl+spacebar for maximizing the editor is in conflict with autocompletion.

Just a note, but this idea that should be used on the Mac where other platforms use CTRL should have been abandoned long ago. It dates from about 1984-87, before Mac keyboards had CTRL keys. (In other words, from before the living memory of most of those reading this.) It makes more sense to treat as equivalent to the SUPER/WINDOWS key.

Beware of CTRL-PAGE_UP and CTRL-PAGE_DOWN — these would conflict with the keystrokes for adjusting the auto IK chain length. Interestingly, this seems to be hardcoded — I can’t find it in a keymap anywhere.

In macOS/OSX is used like CTRL, SUPER/WINDOWS key doesn't have a lot of uses in windows except for OS shorcuts. But is a basic key for anything in macOS and normally is the key that you use for all shorcuts, for example copy&paste is ⌘+C and ⌘+V. Because in macOS you have CTRL but no one uses it in the believe that is hard to use instead the , something that I think that it's true.

Don't know if it has already been mentioned here, but in the Python console, ctrl+spacebar for maximizing the editor is in conflict with autocompletion.

Thanks for pointing this out, it applies to the text editor too, checked and this prevents the console/text-editor from going fullscreen via a shortcut, thats not great, but not necessarily a blocker IMHO. We had similar conflicts in the past for eg with Ctrl-Left/Right being used to switch screens, getting used by the text editor for cursor navigation (no longer a problem with the new keymap).

Looking into this further, we can use Shift-Space for auto-complete, since animation isn't activated from console/text editor, although this would become annoying when typing capital text that contains spaces.


Just a note, but this idea that should be used on the Mac where other platforms use CTRL should have been abandoned long ago. It dates from about 1984-87, before Mac keyboards had CTRL keys. (In other words, from before the living memory of most of those reading this.) It makes more sense to treat as equivalent to the SUPER/WINDOWS key.

Why not have a preference to swap [OSKey / Ctrl] ? It seems this is what Mac users expect, some extra work would need to go into making key shortcuts display properly.


Beware of CTRL-PAGE_UP and CTRL-PAGE_DOWN — these would conflict with the keystrokes for adjusting the auto IK chain length. Interestingly, this seems to be hardcoded — I can’t find it in a keymap anywhere.

I couldn't find this anywhere, do you have an example of how to use this binding?

Control of the Auto IK chain length is documented here. You might remember this patch to the relevant docs.

Don't know if it has already been mentioned here, but in the Python console, ctrl+spacebar for maximizing the editor is in conflict with autocompletion.

Thanks for pointing this out, it applies to the text editor too, checked and this prevents the console/text-editor from going fullscreen via a shortcut, thats not great, but not necessarily a blocker IMHO. We had similar conflicts in the past for eg with Ctrl-Left/Right being used to switch screens, getting used by the text editor for cursor navigation (no longer a problem with the new keymap).

Looking into this further, we can use Shift-Space for auto-complete, since animation isn't activated from console/text editor, although this would become annoying when typing capital text that contains spaces.

I think that the best would be tab, like any other console, but I don't know if it is conflicting with something else, but yes as you said it is not really blocking :)

Good morning everyone. :) Small issue I'm facing. I'm trying to maintain a custom hotkey preset separate from the new default. So whenever the default is being changed/updated (which is the whole point of this task: T55162), I wouldn't have to keep changing back certain/most keys I've setup for my personal workflow. Here's what I noted.

Whenever 'Certain' hotkeys are changed in the Default preset, it's also changed in my Custom preset. (Which is Expected) eg: Recent changes to A / Alt + A for Select/De-Select, Ctrl + Tab for Mode Pie Menu, Etc.

My understanding is, these changes are 'Global' and affect the core keymap code as a whole? Hence why I'm keeping track of this task for changes and modifying my custom preset accordingly.

eg: I prefer 'A' as a toggle for Select/De-Select, and Tab + Drag-Mouse for Mode Pie Menu. So I changed them in my custom preset. Simple. :)

Issue is, when I switched back to the default preset. The above changes have been reflected on that as well. Didn't expect changes made to a custom preset to affect the default in anyway.

Although the opposite seems to be true. Changes made to default affects Some hotkeys on all other presets. Including custom ones. (Again, I expect it with code changes.)

I say 'Some' because I noticed. None of the changes made in yesterday's commits for the 'Keymap Inconsistencies' has made it into my custom profile? But are changed in the default.

The whole point of maintaining a custom preset is so, 1) Not to disturb the default profile in anyway with custom changes. 2) Not having to redo all your personal keybinds every time Blender defaults are changed/updated. (keeping both separate, one shouldn't affect the other. --- Or at least, not so Inconsistently.)

The only way I've found to reset the changes that have mirrored onto the default preset, due to me updating my custom setup is to, Export Custom Preset > Load Factory Defaults > Import Custom Preset.

Would be nice if the Default Input/Keymap Preset is saved 'Separately' from the 'userpref' file. So you can 'Reset Only' the Input Settings and nothing else.

eg: Pablo has been making tweaks to the Default Theme the past couple of days. And it's been quite simple each time I download a new compile of Blender to just hit 'Reset to Default Theme' and have it update to the new changes. :)

Affinity Photo has this section of the User Preferences where you can reset 'Individual' parts of the program. Just an example.

As for the other issue. Some defaults force update the default & custom presets. Others don't. Like the keymap inconsistencies changed yesterday. eg: Image Editor Unwrap: 'U' in default. But still 'E' in custom preset, etc.

Only way I know around this is to 1) Make changes 1-by-1 to my custom preset, depending on what has changed in the default. (this task) 2) Load factory defaults > Modify the keymap (again) with my personal keys, so that I'll get 'best of both worlds', the newly updated defaults/changes and also have my custom keys. And export it for safe keeping. --- But since the new defaults are quite in 'Flux', this is better done when everything is finalized and I'll only have to change my custom keybinds just one time before saving it out. :)

Wish there was a simpler way where, Whenever the 'Defaults' are changed/updated. It will update all the presets. As it does now. But completely. Not just change some and ignore others. And only change/update the keys where the user has 'not' modified. eg: If I have custom set 'Extrude' to 'E'. Then even if the default is changed/updated to 'Ctrl + E' it shouldn't change it.

And if the user wants to update 'Everything' to the new defaults, this is where a Reset Keybinds button would come in handy. :) Would be even more awesome if we could have two buttons. Reset Keybinds (This resets 'all' keybinds to default.) Reset Unedited (This would reset everything 'except' keybinds which have been modified by the user.)

Just thinking out loud. Hope this made sense. If we could make Editing/Updating/Resetting Keybindings easier for new & veteran users alike. Where you can modify keybinds to suit your needs, but not lose the new changes made to the default without disturbing the default preset or what you have in your custom preset. Or at least if merging the two wouldn't be as destructive or difficult. That would be Awesome! :)

I think that the best would be tab, like any other console, but I don't know if it is conflicting with something else, but yes as you said it is not really blocking :)

If we only make tab auto-complete for the console we would need a different key for the text editor since this is used for indentation.
Also the PyConsole supports indentation, although in this case its common to detect initial indentation or typing after existing text.


@Gibran Kaleel (razgriz286), Making custom keymaps is important, especially if we make our keymap more minimal.

However this is a big topic, you raise valid points, but this is out-of-scope for changing the keymap.

@Campbell Barton (campbellbarton) Yeah. It's all good man. :) This is in no way one of those "Fix This Now!!!" requests. I can imagine how much work it will take to have a Keymap system like that, with difference scanning, selective resetting and selective updating, etc. Since we are discussing about keymap changes and also this seemed the most direct place to share this idea with you guys. I hope it's something we can work towards in the future. :)

For anyone who wants the tl;dr from my top post.

  1. Changes to the Default keybinding preset, should not make changes to a user's Custom preset(s).
  2. Changes to the Custom preset(s), should not in anyway make changes to Blender's Default preset. --- It's called Default for a reason. If you've messed up your custom preset. You should be able to just select Default from the list and have a pristine Stock preset.
  3. If for some important reasons, changes to the 'Default' preset code, have to be pushed to the user's 'Custom' preset(s). Then it should be Consistent. --- (Can't have some of the changes making it in, while some others don't.)
  4. Shouldn't allow users to make changes to the actual 'Default' preset. --- Instead, would be better to auto-create a Default.001 copy or 'Prompt' the user to create one when they 1st try to make changes to 'Default' preset.
  5. Shouldn't have to Reset settings for the 'Entire Application', just to reset 'Keybindings & Input Settings'.
  6. Would be cool to have a Reset Keybinds button, which (Only) resets All the keybinds to the application 'Defaults'. (Depending on most recent updates committed to Blender.)
  7. Would be even cooler to have a Reset Unedited button, which (Only) resets All the keybinds. Except ones which have been modified by the user. --- (Basically you get to keep your changes but let everything else in your Custom preset update to match Blender's Current Defaults. Very helpful when changes are made to the Default preset in new compilations.)

Added convenience feature for experienced users: Alt-MMB(drag) for view axis switching: rB1bf5cc57bd15cfaf8c26b50a91a8c5fbab26cb68

Its for experienced users, of course existing methods for changing view axis remains.

Hi, I'm not able to center the 3d cursor with SHIFT+C in 2.8. Is the the shortcut changed or what? or is it a bug? It's really annoying though cause I can't add in new meshes in the center of the scene. Can anyone help me, please?

@James Prakash J C (Artstallion) Hi James, In the new Blender 2.8 keymap, Shift + C > Center Cursor and View All function is not-bound by default. You can find it here. (View > Align View > Center Cursor and View All) --- Feel free to Right-Click > Add Shortcut > Shift + C --- You can also use Shift + S > Cursor to Center.

As for zeroing out the values for 3D Cursor (XYZ) in 'Sidebar' (N) Panel. Not updating in the viewport. It doesn't work properly at the moment. Sure it will get fixed in time. Hope this helped. :)

Who thought A: Select All and Alt-A: Select None was a good idea? It used to just be A, now you've made it 2 hotkeys? This is not how you help anyone.

Also, where is ALT+Mouse scroll to change Frame #s? Did I miss it being moved to something else?

@Brandon Ayers (thedaemon) well the idea is that now you dont have to go through double tapping A, wich meant selecting everything before deselecting, which in heavy scenes was really a big fat mess.

Separate keystrokes for select-all versus select-none is a good idea.

Is there any reason why QUOTE is not used for anything? I posted a .blendfile which binds QUOTE to select-all and SHIFT-QUOTE to select-none in every editor, just to see how it worked in practice.

Artists in the Blender Studio requested separate keys for select/de-select, since they occasionally had selection outside the view and select/de-select cycle isn't as predictable.
(Caused some accidents)

An argument can be made for this being better for heavy scenes too, although on it's own I don't find this argument so convincing.

Btw, as far as I see - nothing prevents us from setting A to be "toggle all / nothing", and Alt-A to "select nothing".

while a deselect hotkey can be useful, removing the utility of A doing both is a mistake for users who are not going to know that A is capable of doing both and are not going to look for that option. In addition to forcing all former users to retouch the hotkey (this and a hundred other hotkeys) to work as traditional Blender.

But after eight years of using blender I don't see that there are any "accidents" with this key that justify deactivating this functionality.

In keeping with the "workflow" mentality, would it be possible to get a context-based deletion behavior by default when pressing "x"? Like the Smart Delete addon.

In Blender, it's always a two step process of having to go through the delete menu then selecting the desired delete option. If it was made smarter, it'll just help speed things up physically, but also mentally, so the user doesn't always have to pause a split second to think about which deletion option to use every time.
For the rarer cases when needed, the Delete menu should be accessible via a hotkey.

Also, there should be an option to disable confirmation for stuff like deleting objects. There seems to have task for this very reason (https://developer.blender.org/T37422), but unsure what happened.

@Campbell Barton (campbellbarton) Hey Campbell. Just checked out the list of 2.8 keymap changes. Looks pretty good. :) Think it would be good to mention both instances of Playback Animation? --- Playback Animation (Fwd): Shift + Spacebar / Playback Animation (Bwd): Shift + Ctrl + Spacebar

It would be neat if there was a "cycle" option for the "type" selector in the key binding menu. I'd like to press "z" and it goes to the next mode of shading

is there a way to set up search as double space?

F3 doesn't work from the toolbar menu and it's just personally irksome to have to take my hand out of typing position when i'm about to have to type.
setting it as double click spacebar seems to be ruined by the toolbar popup on space.

I dont see how Select-all can be unpredictable, for me it works fine.

I tried the last blender, please make a A - toggle selection again its freakin anoying how it locks blender.

Continuously pressing A is way more plesant than having to think "Wait this is not Alt, I pressed the wrong button again"

Find-operator should be on /. This is the key used in Gimp for its search function.

F3 doesn't work from the toolbar menu and it's just personally irksome to have to take my hand out of typing position when i'm about to have to type.
setting it as double click spacebar seems to be ruined by the toolbar popup on space.

Fixed rBb2d8f834446c5545efae8a824a6197e2b338ec00

Find-operator should be on /. This is the key used in Gimp for its search function.

Agree, would be nice to use this for searching (edit, this is used for search in other applications too - Firefox, Vim, even Facebook & YouTube use this).

OTOH, why would the default search function search for tools? - Wouldn't it be useful to add the ability to search for content, based on the editor type based on names, or file paths, or asset tags? (objects, images, layers, sequence strips .. etc)

OTOH, why would the default search function search for tools? - Wouldn't it be useful to add the ability to search for content, based on the editor type based on names, or file paths, or asset tags? (objects, images, layers, sequence strips .. etc)

why wouldn't it search for tools? sometimes you know the name of what you're wanting but not the hotkey, not everything has a hotkey, sometimes tools are added with addons (like looptools for example).
though i agree it might be useful to add the ability to search for other things.

This comment was removed by Campbell Barton (campbellbarton).
This comment was removed by Campbell Barton (campbellbarton).
This comment was removed by Campbell Barton (campbellbarton).
This comment was removed by Campbell Barton (campbellbarton).

While none of the comments removed just now were inappropriate, the general direction was moving off topic.

Turning into forum style back and fourth only loosely related to this design task.

For more general discussions relating to Blender's keymaps, post here:

This comment was removed by Campbell Barton (campbellbarton).
This comment was removed by Campbell Barton (campbellbarton).
This comment was removed by Campbell Barton (campbellbarton).

@Jean Da Costa machado (jeacom256), please move discussion to the links posted above.

If you have a statement which you feel helps this design task progress, make it. But try avoid noisy forum comments/disagreements here.

Numpad + / is used in 2.79 as Local view. / could be used for keyboards without numpad and numpad emulation mode as there is no key for this action when numpad is missing. But as ~ is used in 2.8 for view pie menu, then maybe some ~ related shortcut is needed like e.g. Alt + ~

@https://developer.blender.org/p/looch/ Heavy scene issues make sense about the alt+a hotkey. Selecting everything can be a killer. I can always customize my hotkeys :)

for compact keyboards without a numeric keypad, convenient shortcuts are required for the very essential "frame select" command (numpad .)
and also for the "local view" command (numpad /)

There's no option to select and toggle v/s/r recursively in outliner. Ctrl key is now used to isolate selection by ctrl+clicking on visibility icon (but seems like without possibility to reverse action as alt+H shows all objects regardless of state). Maybe alt or shift +click on object icon and v/s/r icons can be used for this now (as previously ctrl), as this is feature is essential for working with parented objects.

Most tools in edit mode leave the current selection selected so that you can continue doing other actions to the selection. If you are done and want to see how the action looks like without distracting selection highlights, you have to deselect. It is always a thing you do, you deselect after doing anything, to see how it looks. Previously it was super easy with "a". Now it is cumbersome with "ctrl-a". "A" now is the super rarely used "Select All".

I'd rather switch these two, "a" deselects all, "ctrl-a" selects all. That, or keep "a" for selection, and use another key without modifiers for deselection.

Or, you just go to the Tool Shelf, expand the Display panel, and uncheck and recheck “Outline Selected”. No need to actuallly change the selection at all. Simples!

Juan (ancientbuho) added a comment.EditedAug 12 2018, 5:52 PM

Or, you just go to the Tool Shelf, expand the Display panel, and uncheck and recheck “Outline Selected”. No need to actually change the selection at all. Simples!

Thank you but sorry, that doesn't help.

First, it's way more work than even alt+a, considering that you'll have to re-enable it to be able to start new selections and that it's quite buried between other options.

Second, it doesn't work with selected vertices in edit mode.

Third, being able to quickly deselect is still quite important - removing the highlight is just one reason. This is why I deselect:
+ Clear selection after doing a set of actions. Example: extrude a face 4 times. "a" to deselect. Ctrl+click to lasso-select new vertices. If you don't do "a", you add to the previous selection. Super-common use case.
+ Clear selection after selecting the wrong things to start over.
+ Clear selection before navigating somewhere else in the scene. Why? You don't want to leave stray things selected that may be accidentally added to new selections.
+ Clear selection to just make sure nothing is selected before doing something.

Really, I didn't know how much the "A" key was used after I tried 2.8. With the exception of right-clicking to select, every selection tool (lasso, box, circle select) adds the new selection to the previous selection without modifiers. That's awesome, and allows for quicker workflows. This behavior relied on a quick deselection shortcut for it to not be annoying though.

Other graphics software (I am thinking of 2d vector programs) clear selection via other means, such as deselecting when clicking outside of the selected items. But Blender doesn't unselect when clicking outside of the selection because that's used for "grab / move" the selection. So, "A" was filling that void.

Hi! I was wondering if changing V / Alt-V for controlling the backdrop zoom in the compositor had been considered yet, I've always found that confusing and to me it doesn't really make sense.
Maybe that could be assigned to Alt-Mouse wheel, it would be coherent with Alt-MMB currently used to move.

Alt + A for deselection is freakin anoying for sure.

Could I make a suggestion?

Pie meus are the best workflow assist that any user has ever seem.

Lets apply the same solution that was taken on Tab for edit mode:

Just make A invoke a Pie menu with several selection options if it was dragged, in special: Deselect and Invert.
If there's no drag event it behaves like before.

Just to give my opinion without trying to generalize what I personally like, with what others may like or suits them.

I do not feel comfortable with Pie Menus, I do not use it.
About Alt+A, I have found certain advantages to this new behavior and in fact I have started to like it. For example you do not need to be looking at the screen and analyzing the scene to be completely sure that you have selected or deselected all.

I am not able to find the shortcut to set origin in 2.8, earlier it was ctrl+shift+alt+c, anyone knows what is the shortcut in blender 2.8?

@vikrant singh (vikrantsingh47) Hi Vikrant, It's currently not bound to any shortcuts for the default 2.8 (minimal) keymap. You'll have to manually create/bind it in the input settings.

User Preferences > Input > Expand 3D View section. --- Under 3D View, look for Object Non-modal section. Then click on Add New button. --- Then paste this operator line into the empty box; object.origin_set -- Set keybind to Shift Ctrl Alt C, as shown in the image and you can have the Set Origin functionality back as before. :) Hope this helped. Cheers.