Page MenuHome

Default Keymap: Revamp
Closed, InvalidPublicDESIGN



The current keymap in Blender 2.7x has become overly complex, messy, and very inconsistent. It needs to be reworked. There's too many cases of inconsistent workflows, complicated modifier keys, and in general there's just too many hotkeys for anyone to practically manage.


To create a new, more minimal default keymap that creates an effective workflow for the most fundamental tools while leaving plenty of room for customization by the user.

This keymap will not attempt to map every tool for every editor. It will attempt to offer a solid set of defaults for key tools, leaving the rest up to the user.

This revamp should address, at the bare minimum, these items:

  • Make selection methods consistent across editors (including Left / Right select)
  • Make selection modifiers (add / remove) consistent across all selection tools
  • Make it easier to learn by reducing the number of hotkeys and improving consistency across editors
  • Rely less on obscure hotkey combinations with lots of modifier keys
  • Prioritize the operators that get hotkeys by default
  • Make hotkeys consistent across editors for similar tools


Keymaps are difficult and complex. Initially this keymap will address Selection Tools for all editors(T37420) and the essential 3D View editor operators. After selection and the 3D View are satisfactory then work will move to the other editors.

Current Status

Myself, @Jonathan Williamson (carter2422), am working on the initial keymap, which will be tested and discussed amongst the UI Team first, followed by testing by select active users. After select testing and reviews are finished it'll be opened up for additional discussion and input by the community.

Progress is slow, but ongoing.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Albert (wevon) added a subscriber: Albert (wevon).EditedOct 27 2014, 9:07 PM

For Pie Menus, based in pie piece distribution and left hand's position , I think sould be better to use QWEASDZXC short keys instead 789456123 (or both).

It's easier to remember the position than a underlined word.
One click to open the pie and another click to choose a piece is faster than 1 click for opening the pie and a mouse gesture.

Like the picture, I prefer grid distribution too. It's more structured and easy to read.

Status: We are slowly getting closer to the new keymap thanks to the pie menus being functional and in master, and sticky keys getting closer.

I took a stab at facing the keymap problem outlined in the task's description.

The obvious solution when you have too many elements to manage (which is one of the problems here - too many shortcuts to remember) is to bundle them into categories. Blender does this already in a way - a bit with double tapping (G, G for slide), but mainly with modifier keys - for instance scale is S, shrink/fatten is Alt-S in Edit Mode, and Clear Scale is Alt-S in Object Mode.

This works, but the problem with the Alt, Ctrl and Shift modifiers is that they are a bit generic - they were made with different meanings in mind (Alt was meant for the numeric keypad for instance), but for shortcuts they are just keys with different names.

And the biggest category size with this system is 3, unless you use no more than one modifier key, which gets messy.

But with pies + sticky keys we could make this better:

So here are most of the modeling operators, bunched together as much as possible into categories that are easy to remember. For instance 1 is all about Vertices - pressing changes the select mode to Vertex, holding displays the Vertex menu.

Sometimes pies would work better, and sometimes menus (looking like the current ones, for instance Ctrl-V in Edit Mode). But to keep the user experience consistent, the menus fired by holding a key would work like pies fired when holding a key - releasing the key over a command would fire it (instead of LMB-clicking).

I marked which is a pie and which is a menu in the mockup with icons and descriptions.

The keys chosen are a blend between current Blender's shortcuts (S for scale, X for delete, E for Extrude, F for Make Edge/Face, Z for Toggle To Wireframe), the way the keymaps are set up in other applications (Move, Scale, Rotate being next to each other, no more A for Select/Deselect All - click on empty space or Ctrl-A instead), a letter from an operation's name for easy remembering (C for Cut, R for defoRm), and related functions being close to each other (Q operates on the pivot of your operations, W operates on the orientation of the operations).

I would love to try a prototype, if anyone likes the ideas here.

@Paweł Łyczkowski (plyczkowski)

Looks decent. One of the things I would recommend for the spacebar instead of the view navigation menu, is a viewport type menu, this is something that is in this pie menu addon.

I think that would be better than the SHIFT F1 stuff. Even if it doesn't go to the space bar, I think it should be a part of it.

@TARDISMaker Ooh, that looks mightily helpful, thanks.

Looks good, all around WASD like a FPS :)
If you use space for viewports, you could have views in V (since rip is in C-hold)

Modifiers could be given meaning. For many tools Alt works like a "negative" modifier (alt+g, alt+s, alt+i, etc.). Editor generic shortcuts could be in Ctrl, like ctrl+up, ctrl+z, ctrl+s, ctrl+q, etc.

Count me in for a proto.

and related functions being close to each other (Q operates on the pivot of your operations, W operates on the orientation of the operations).

Unfortunately, this remark is only true for Qwerty keyboards.
On other keyboard distributions, ASD are not keys close to each other.

Unfortunately, this remark is only true for Qwerty keyboards.
On other keyboard distributions, ASD are not keys close to each other.

Yeah. Can't do nothing about that.

In many programs, ERT are used for scale, rotate and translate because it is what works better on different keyboard layouts.
Y could be used for extrude and inset.

A cool thing about blender keymap is that it is easy to remember because it uses operator initials.
IMHO, keeping this for two basic keys is better than one.
G could be a perfect shortcut for pivot menu. it is next to these 3 keys like Q is next to ASD.

Q could be used for snapping.
IMHO, S should be used for Select, Select menu, Name picking. Out of the scope of pie-menu, as direct shortcut, in object mode, It can replace alt right click that no newbie fighting with selection in 3D view knows.
In edit mode, it could be select linked pick.
A should be used for Add in general to add objects but also modifiers and constraints.
D should be used for Duplicate.

I think this proposal is not so far from yours.
I really like your proposal and I tried to complete it with other basics of Blender.

Good refactor :) Holding keys would be reealy cool. That's how they dealt with complexity in mobile OSes.

Proposition: [5] for Item selection mode. like [L], but not additive. Super useful when you have many rocks or something combined into single meshes for optimization (eg for games).

@Avenger (avenger) Select Linked could definitely be done better. More ideas about how to refactor selection can be found here - (Select Linked is double click there, with shift to add and ctrl to remove).

@ronan ducluzeau (zeauro) - You mean W,E,R keys, right? I don't know any 3d app that use E,R,T keys for that but I worked on 5 programs that use W,E,R.

@Paweł Łyczkowski (plyczkowski) - I very like your proposition but there is one big issue. Toggle select (A key by now). We all just need this as a shortcut to work efficient in blender, especially for deselecting things. Also Manipulator (W) key is unnecesary imho, toggling it isn't used often.

I think we better place Move, Scale, Rotate operators to W,E,R(otate) keys, just like in other apps. This is very comfortable setup and we will get standard-like keymap used by bunch of others softwares. Which is, in fact, good decision. There is nothing bad with copying ideas if they are well designed and appreciated. Solution like that will fit nice to 1,2,3 keys. We will get undeniably most used hotkeys in one place. :)
We "loose" E key for Extrude but I think this is no big deal, since in both concepts keys won't be named after operator initial (A for rotate in yours or W for move in mine).

Q key. Since we have nested pie menus, maybe we can use if to some king of Super Pie menu that will contain most used things? User hit Q key and see first menu that show him options like Pivot Point, Transform Orientation, Snap Element.

Below "transformation bar" with move, scale and rotate we can have "create bar" with A for Add menu, F for Make face, D for Extrude (Shift D for Duplicate like now). We still have S key that can be used for Selection toggle and Selection menu when held.

Z,X,C bar is perfectly fine.

How about that?

I admit it. I did not touch other 3D software since a while. In fact, A Z W Q for Rotate, Translate or Scale is problem for me.
I searched something that worked on my azerty and on qwerty keyboard layout.

The re-reading of paradigms for selection make me think that we must keep a keymap without sitckey, without pie-menu as a modifier to resolve the conflicts with all actual uses of LMB and modifiers keys .

quick extrude, tag edges, vertex path.
Theses little things that makes our edit mode quick and intuitive.

@Bartosz Moniewski (monio) About the A key - it's very non standard and painfully breaks habits from other software. I would go with a more standard click-on-empty to deselect, and move current functionality to Ctrl-A, for selecting all, and those rare cases when you don't have an empty space to click on.

I say painful because it's painful to me when I have to tell my students "I can see you are clicking on empty space trying to deselect, and pressing Ctrl-A to select all, but that's wrong" - but in reality, it's actually right.

W, E, R and a Super Pie could work. I would like to see some designs for the Super Pie, with emphasis on transformation pivot and orientation being readable and accessible.

CTRL+A for Select All is fine for me. Maybe double tapping A While holding CTRL will work for deselecting all. We still can use Shift+A for Add menu like now.

Click-on-empty... Are we stitching to Selection by LMB? If yes, this can be very tricky with using manipulators. People will be deselecting by accident very often. We first need highlight on manipulator handles to approve that. Selection is very interrelated with keymap. I think we make some decisions on this first.

Also. @Diego Gangl (januz) proposed nice thing about modifier keys. This must first be applied to selection. Then we can build rest on top of that.

@Bartosz Moniewski (monio) Well the Manipulator handle is obviously not empty space.

But we have no feedback that tells when cursor is close enough to grab it. You click some pixels next to it and you grab vertex but one pixel further you will deselect all.

@Bartosz Moniewski (monio) makes a very good point! If pressing outside the mesh deselects all, then when the manipulator is in grabing position it should pop out more, or change color, so that we can distinguish whether it's going to grab the manipulator or deselect all. The same with vertices. In maya if you hover over a vertex it changes color, to tell you that if you press LMB it will select that vertex.

Well, I certainly agree 100%. I'd love to get pre-selection highlighting in Blender, but so far the official word's been 'no'.

In that case I think it may be less frustrating if we just kept to a key that toggles between select all/deselect all (the "A" key), for now.

I don't agree. I think @Bartosz Moniewski (monio)'s example wasn't a problem. As @Paweł Łyczkowski (plyczkowski) states, it's clearly not empty space.

@michael knubben (michaelknubben):
The question is, how far is it not empty space? The grab widget is just one pixel wide, surely you do not always click exactly on this thin line, but somewhere close to it. If there is no feedback, you sometimes miss the widget. With this change you would then deselect all, which would be pretty frustrating.

@Paweł Łyczkowski (plyczkowski): By the way, the Z button is on the top row (QWERTZ) on many keyboards in Europe. Not suggesting to change anything because of this, I think we'll just need to live with it, just as with the old keymap.

@Zsolt Stefan (zsoltst)

you sometimes miss the widget

Do you currently miss the widget? Because I haven't heard any other complaints about the active area being too small. If you do, it's controlled by a setting in the Preferences: Interface > Manipulator Hotspot.

Pies + sticky keys seems a good combo, this way we have direct actions and menus in one key. Anyway I think using pie menus without sticky keys and QWEASDZXC for accessing to pies actions would be faster. For instance: W for opening Transform Pie and Q to active Translation gizmo. Never mind, pies and sticky keys seems good option too.
On the other hand, I would use C for positioning 3D cursor, and holding i t for opening snapping object and cursor menu. It would leave left mouse click for other purposes.
Long time ago, I mixed Nathan's experimental hotkeys with standard hotkeys and I got and interesting behavior:

·1 rotate camera + 2 holding Alt -> snap view
·1 holding Alt +  2 rotate camera -> Set camera preset (front, top ...)

@ronan ducluzeau (zeauro) I think SDF are better than ERT (or WER) for the transform keys (a.k.a. scale, rotate, and translate).

Basically, the transform keys are some of the most commonly used keys in Blender, right up there with viewport navigation. So a user's hand will naturally end up resting on or near those keys by default. In other words, wherever you put the transform keys is like a resting position for the user's hand, so we want to make sure that's a good resting position.

SDF are a better resting position for at least three reasons:

  1. It corresponds to the home row, which is easy for new users to learn and remember.
  2. SDF are surrounded by a full ring of other hot keys, which maximizes the number of hot keys that can be comfortably reached without moving the hand.
  3. Reaching the modifier keys from a resting position on WER is painful.

In general, from an ergonomics standpoint, I think it's best for the default resting hand position to be over SDF, and then for the most commonly used hotkeys to be on the ring of keys surrounding them (although we have to balance that with mnemonic concerns).

@Nathan Vegdahl (cessen) Good to have you here.

Regarding Move, Rotate, Scale - I still would go with ASD rather than SDF - easier to reach 1, 2, 3 for switching selection modes, easier to reach Ctrl, Shift, Alt and Tab, which are quite important. In WER these problems are even more prominent.

@Paweł Łyczkowski (plyczkowski)

Just some thoughts on the current topic of WER/ASD/SDF

There are far less cons with QWER than with ASD (Q being deselect, or any other action). I cant help but feel this idea of WER being painful is a bit unrealistic and a exaggerated (especially given its popularity).

Not all hand sizes are the same, I'd argue most conventional keymaps use WER for transform or primary handplacement (thus making adoption easier, have yet to see any pro using WER in other software apps complain about access to modifier keys), Gaming on PC also conditions players to rest fingers on WAD (which they have no problem with modifier keys). There is just very little to gain by going away from the QWER strip, especially if its just a minor move down to ASD.

When we rest our hands flat out on a keyboard, with the middle finger touching W, the natural placement of the other finger tips start lining up distance wise to the modifier keys, thus the near universal use of WASD for gaming. If we consider then than both software users and gamers (often theres overlap) have been conditioned with that kind of placement/expectation in mind, there's very little to gain by deviating from it. Power users who prefer alternate setups can do just that on their own, so its far more beneficial to play into that WER/WASD hand placement users have been conditioned to use as a default.

2cents + a bit of the K.I.S.S. philosophy at play (keep it simple stupid).

@Paweł Łyczkowski (plyczkowski)

How about spacebar for views like you already have it, and shift+space for viewports?

I think giving the viewports the biggest key on the keyboard by its self is a bit of a mistake. I think it would be more useful to have the views pie menu, because if we work on moving the keymaps so that they are within reach, people (me at least) would rather use the key that's closest to the resting hand position for side, font, etc. views, than to have to more the hand away for that side of the keyboard or the mouse to get to the numpad.

Also, what about making the add menu be something like shift+f? Shift+a is a bit awkward with the hand on the home row for me.

@DataDay (DataDay):
The only full-suite 3d apps I'm aware of that use WER are Maya and 3DSMax. Houdini and Cinema 4D both use ERT, and XSI uses XCV.

In any case, you have to look at both viewport navigation and the transform tools together.


Transforms: WER
Viewport: Alt+Mouse


Transforms: WER
Viewport: Alt+Mouse


Transforms: XCV
Viewport: S+Mouse


Transforms: ERT
Viewport: Spacebar+Mouse

Cinema 4D:

Transforms: ERT
Viewport: 1/2/3+Mouse

The reason why top-row keys work for Maya/Max/Houdini is because their viewport navigation is still reasonably accessible from that hand position. Alt is fairly accessible from your thumb when your hand is resting on WER, and spacebar is extremely accessible from your thumb when your hand is resting on ERT. However, Shift and Ctrl are quite painful when your hand is resting on WER/ERT, so that wouldn't be a good fit for Blender unless we also plan to change viewport navigation away from MMB+Shift/Ctrl.

And incidentally, I don't think Maya is good reference for ergonomic layout anyway. For example, selection-mode switching is on F9-F12, which either forces the left hand all the way over to the top-left of the keyboard, or forces the right hand off of the mouse. And if you're left-handed it's even worse.

For Blender, I really think that the middle row makes the most sense for the hand resting position.

@Paweł Łyczkowski (plyczkowski)

That's a good point. With ASD you gain a better hand position for viewport navigation, selection mode switching, and tab-mode switching. And Shift and Ctrl are also used heavily for selection, so that makes them even more important.

But I do think SDF has some benefits that are worth considering as well:

  • The three extra accessible hotkeys due to having a full-ring of surrounding hotkeys. This is most useful when doing tasks that involve a lot of tools, like mesh modeling.
  • It's easy to find SDF by feel due to the raised bit on the F key of most keyboards, so when your hand does have to drift away (which is inevitable) it's easier to return to that position.
  • The pinky finger isn't on the useless capslock key by default.
  • We can still have A as the hotkey for select/deselect all.

And SDF is still pretty good for Shift/Ctrl/1/2/3/Tab accessibility.

So I think I would lean towards SDF over ASD. But honestly, I would be happy with ASD, too, if we end up going with that.

@DataDay (DataDay)
It also occurs to me: your point about WASD from gaming is actually an argument in favor of @Paweł Łyczkowski (plyczkowski)'s ASD suggestion, not WER. ASD and WASD share the same resting hand position, whereas WER is both up and over from that.

@Nathan Vegdahl (cessen)

I respectfully disagree with that assertion. First a couple of points:

Its not just full 3d suites we have to consider, but a wider range of 3d applications with some form of transform widget and 3d navigation.

Its not uncommon to find people asking how to change non QWER control based apps into QWER.

Modo which you left out and is quickly growing in popularity also uses QWER. I'd argue it has one of the best keymaps to date thats extremely consistent across its entire UI.

I mention Q, which you leave out because its part of the control scheme for quite a few of these applications. Q is hiding or full on deselecting of the widget.

This leads to why WASD does not argue in favor of ASD. The key is where the middle finger rests and the circle of influence around that point. Its better to err on the side of people also having longer fingers/bigger hands than smaller ones. I know I don't have large hands compared to some, but resting fingers on ASD pretty much means the thumb will not rest naturally on or near the space bar or alt buttons. In fact it requires far more of a claw like grip, which is not ideal.

There are far more applications using the QWER strip, which ups its conventional status. Also keep in mind, most trade schools and colleges are teaching their students through Maya, as students they also have access to the software for free. This means the masses are building habits built around that one strip. I can gaurantee you most students and those learning 3d wont come out of school ready to lay down $3500 for a maya license. The natural progression is to find alternative software, of which, Blender is the most likely and accessible app for them to try next. Best to help them fit right in, feel comfortable. Additionally, because of the convention, its easy to take Blender with them into work environments and studios, thus making adoption easier as well. In short, there are just too many pros and not enough cons to warrant moving away from that strip and finger placement around the W key.

Finally QWER should not be the only method to access and hide transform tools. When building around tablet workflows, UI and or pie menu options need to be present as well. Thus I believe between the two you have the most accessible, conventional, consistent, and natural (hands form factor) placement with that layout.

On the subject of Maya's layout.. its more or less built around the hotbox (spacebar) and marking menu. Its a very spacebar centric layout. I'm not arguing for copying Maya or any other keymap directly, thats not what this place should be about, but rather focus on the convention and usability that can empower blender in the CG world. With the development of Pie Menus and nested menus, this presents a new dynamic which should be taken into heavy consideration with the revamping of the keymap, as it can keep it extremely simple and let the user make use of many more custom keys for their own workflow.

More 2cents

I am happy to learn that I did not dream. I really worked with 3DSmax users using ERT (french ones).
So, also a significative amount of american/english pros are using ERT.

@Nathan Vegdahl (cessen), no doubt that on an azerty keyboard SDF is more ergonomic than ASD.
I would be in favor for this if I used a qwerty keyboard because of this "The pinky finger isn't on the useless capslock key by default."

But I would like that the new keymap will not be a too much traumatic change for old users and stay still easy to remember.
I loved that plyczkowski kept F for make face.

So, I still vote for ERT.

@DataDay (DataDay)
Good point regarding Modo--I keep thinking of it as just a modeler, but clearly it's a full suite now. But, again, Modo follows the approach of using Alt + Mouse for viewport navigation.

And regardless, this is hardly a universal standard, as Houdini, Cinema 4D, and XSI show (and I'm sure some others as well). This is not like left-click select which is downright ubiquitous not just amongst 3D apps, but nearly every application currently in existence.

It's also worth noting that the interaction model of Maya, etc. and Blender are quite different to begin with. In Maya etc. pressing W/E/R brings up transform widgets, whereas in Blender pressing G/S/R immediately starts moving/scaling the selection. In other words, Maya etc. take a more "photoshop tool" approach, and Blender takes a more "gaming controls" style approach. So even if we make the keys the same, they aren't actually mapping to the same thing. The user experience is still very different. And we would still have different viewport navigation, mode-switching, etc. as well.

I guess I just don't see the consistency-with-other-apps argument as very compelling in this case. By-and-large 3d apps adhere to expectations of general computer applications, but not to expectations from other 3d apps. And user's expectations tend to reflect that. Right-click select makes people run away screaming, but ERT/XCV/ASD/SDF transforms don't, because the expectations of adhering to WER just aren't that strong.

This leads to why WASD does not argue in favor of ASD. The key is where the middle finger rests and the circle of influence around that point. Its better to err on the side of people also having longer fingers/bigger hands than smaller ones. I know I don't have large hands compared to some, but resting fingers on ASD pretty much means the thumb will not rest naturally on or near the space bar or alt buttons. In fact it requires far more of a claw like grip, which is not ideal.

Keyboards are designed for maximum accessible reach from the home-row, which is why standard typing position is on the home row. And spacebar is perfectly accessible from there. (Alt is always a bit awkward, no matter where you put your hands... but I'd argue ASD is less awkward for Alt than WER.) And why should we assume larger-than-average hands? Unless I'm missing something major, designing for average-sized hands would make the most sense.

In any case, it sounds like your assumption is that with WER the user's strongest fingers would actually be resting on ASD/AWD as with gaming, hence your gaming-implies-WER stance. With that assumption the user will have to reach up/over to hit E and R.

The point I'm trying to make is that the transform keys are so fundamental and frequently used that the user shouldn't *have* to reach for them. That's why I said that gaming's WASD is actually an argument for ASD: gamers rest their fingers on ASD/AWD because those are the keys they're actually going to be pressing. The whole point of WASD in gaming is to minimize reaching for the most important keys. If WER were better for that then gamers would use WER. But they don't.

@Paweł Łyczkowski (plyczkowski)

The more I think about it and the more I play with my keyboard, the more I'm leaning towards ASD now. I think you're right: the additional comfort outweighs the reduced accessible hotkeys. And as your map in your post above shows, there are nice ways to group tools together for easy/fast access.

Speaking of your map, I have a few thoughts:

The fill/create-face tool also creates edges if only two vertices are selected. This works great in most cases, but if the two select vertices share a face then it ends up creating an edge that *looks* like it splits the face but doesn't in reality. This is (I'm pretty sure) never what the user wants. In my keymap I made a custom operator that behaves the same as the fill operator *except* in that one case, in which case it calls the connect operator instead to actually split the face. Using this setup has been really nice.

I also made a context-sensitive dissolve operator to complement the context-sensitive delete operator. In box modeling you dissolve a lot, and having to think about what kind of dissolve you want (vertex/edge/face) is as annoying as thinking what kind of delete you want. I mapped it to shift-x to make it convenient and because it's so closely related to deletion.

Lastly, one of the things that I really liked in XSI was that you could hold the transform keys down to temporarily reveal the transform manipulators. This made a really nice/fluid/fast workflow where the manipulators were a temporal thing, rather than a persistent thing. I always miss this when using other manipulator-based apps like Maya. So what if we did the same thing with our transform keys? Tapping the translate key would put things in to translate mode as per usual, but holding it down would reveal the translate manipulator which the user could manipulate and then release the translate key when they're done and it would vanish. (I hope I'm explaining this well.)

@Nathan Vegdahl (cessen)

The fill/create-face tool also creates edges if only two vertices are selected. This works great in most cases, but if the two select vertices share a face then it ends up creating an edge that *looks* like it splits the face but doesn't in reality. This is (I'm pretty sure) never what the user wants. In my keymap I made a custom operator that behaves the same as the fill operator *except* in that one case, in which case it calls the connect operator instead to actually split the face. Using this setup has been really nice.

That sounds awesome. But it's less related to the keymap, and more related to how the operator works. Talk to @Campbell Barton (campbellbarton) maybe?

I also made a context-sensitive dissolve operator to complement the context-sensitive delete operator. In box modeling you dissolve a lot, and having to think about what kind of dissolve you want (vertex/edge/face) is as annoying as thinking what kind of delete you want. I mapped it to shift-x to make it convenient and because it's so closely related to deletion.

Sounds good. What I would like to see is a menu that looks something like that, where basic Delete and Dissolve are context-sensitive, and sub-menus provide greater control to advanced users:

Lastly, one of the things that I really liked in XSI was that you could hold the transform keys down to temporarily reveal the transform manipulators. This made a really nice/fluid/fast workflow where the manipulators were a temporal thing, rather than a persistent thing. I always miss this when using other manipulator-based apps like Maya. So what if we did the same thing with our transform keys? Tapping the translate key would put things in to translate mode as per usual, but holding it down would reveal the translate manipulator which the user could manipulate and then release the translate key when they're done and it would vanish. (I hope I'm explaining this well.)

I like that. And it would only work with ASD - any further right and pressing and holding Shift/Ctrl, which are vital during transforms, would be very difficult. It also solves in a way the manipulator getting in the way of LMB select dilemma.

@Paweł Łyczkowski (plyczkowski)

So, is what you mean something like:
tap "x" = delete context-sensitive
hold "x" = delete menu appears

@Nathan Vegdahl (cessen)

I really like holding key for the manipulator. Sounds really clean.

Just a picture for how I would rearrange the keys, mainly for edit mode.
I like GRS.

After trying ASD setup , i think it is not a bad setup. I managed to get use it in couple of minutes. Keys being together helps a lot here. It is definitely better than a AutoDsk "QWER" setup. However I am not fond of "1-2-3-4" mesh element select. This is the 3dsMax default setup for the same mesh elements and it works if "Select-Translate-Rotate-Scale" are "QWER". I think with "ASD" they are kind of "not near enough" for fast switching.

Personally I wasn't very happy with it when using max; I can't say I'm fond of it now either. Of course they are a logical choice just because of their proximity but there is also " EFV " just right of ASD... at least generally for most keyboards.

E        = Edge select context

A S D F = Face Select context

V   = Vertec Select context

Anyway, I'm sure you'll come up with something. By the way is there any plans to change the vertical tabs to "horizontal" or to "icon tabs" , they give me a headache everytime I use them....

Considering all discusion I also vote for A-S-D setup. Those keys will work nice with standard blender navigation and also with "emulate 3 button mouse" navigation style. Many users (including me) enable this options because they find pressing scrollwheel uncomfortable.

1-2-3 keys for mesh elements won't be as handy like with W-E-R keys but still this is great improvement over CRTL-TAB. We also have Pie menus that will improve changing mesh elements mode.

I don't like context sensitive deletion under X. This option can be extremally destructive in other modes than face selection. This option delete things without user confirmation and in many cases in diferent way than user want. To be exact- deleting edges without deletion of conected verices.
Imho there are two ways to solve this:
A. Leave X and CTRL-X like they work now.
B. Add mini menu under X (probalby 2-3 options) where user define what he want to do. This also solve problem with confirmation and things deleted by accident without giving feedback to user.

Vote for ASD — it's much easier to access Shift, Ctrl, Alt keys. And allows to put context menus for Edge, Face, Vertex on E, F, V keys.

Takanu added a subscriber: Takanu.Nov 24 2014, 12:14 AM
Takanu added a comment.EditedNov 24 2014, 1:41 AM

I really like the proposal after viewing it again, this should bring a lot of needed consistency, while also giving shortcuts to tools that have needed it for a while (Proportional Editing Options, Pivot Snapping, etc). It also cleans up the Face/Edge/Vertex menus nicely :D

I disagree with others that W-E-R should be used as a translate standard and would vote for ASD due to it's centralised position on the keyboard, but I do have a few issues and questions with this proposal:

  1. Will toggling through translate modes in your proposal work the same as they do currently, by tapping the button again to cycle through Global/Normal modes?
  2. The 1-2-3-4 keybinds as i'm sure you're aware, stop them from being used to switch between layers. I think a potential solution could be found like the Move to Layer menu, although I did like switching between layers. It might be more of a concern if some people frequently make use of layer switching, but this is something I could live with ^-^. May be something to look into.
  3. I'm not sure if the select menu has too many options, the menu itself seems really long. I like the idea of having all those options but I'm not sure if its practical.
  4. You removed some potentially useful features from the Face menu like shading options, although this could probably be best fit into another category of it's own now that shading can be marked based on edges and vertices as well.

One thing id like to bring attention to on the subject of keymaps is that on Mac OS X, most keybinds aren't using CMD instead of CTRL. I don't think CMD should be treated as a different key for the default keymap, as it sits in the same position as CTRL would be on a regular keyboard, and on a Mac keyboard CTRL is moved almost to the bottom left of the keyboard. As a result when CTRL is used with most keybinds in Blender, it requires you to either take your hand off the keyboard or flex your thumb under your hand awkwardly to reach it on a standard Mac OS X keyboard. Ensuring CMD is substituted for CTRL, or to make CMD and CTRL the same keymap (so standard keyboards can be also used with a hypothetical Mac OS X version) would make it a lot more comfortable to use.

EDIT - One more thing id like to say in regards to @Nathan Vegdahl (cessen) and his idea for using SDF for transform controls. I think it would be better than ASD if it wasn't for the fact that it makes accessing the CMD/CTRL button more uncomfortable.

I would like to share my opinion as former MAX user and current MAYA and BLENDER user.

I have 3 suggestions (wishes):

  • WER keys
  • LMB select and combinations
  • Unchain keymaps :)

WER vs. ASD, or any other combination:
I have few reasons to vote for WER keys:

  1. Be open to users from PRO packages, they are using WER



Lets be open to PROs.

Few of my colegues wanted to try Blender but it is "too original" as they said.
Unfortunately from my point of few this is one of the biggest CONS of most opensource and similar apps.
It is trying to be as original as possible even if it is annoying.
Please take it easy it is just my experience :)

  1. Be compatible as much as possible with PRO packages
  2. A for....move? it is kinda conflict with CTRL+A select all which would be nice to have
  3. D for....scale? it is kinda conflict with Duplicating which I would expect ( SHIFT+D ) or problem with S :D
  4. 123 is greate for switching elements with only one button - old habits from MAX :) dont agree to use it as default for manipulating
  5. We can remap it anyway:)

I support the idea improving blender keymaps. Please be sure that I dont suggest to copy my favourites :) Rather suggesting to INSPIRE from BESTS and make it even better. Because the Blender is great software, it should seek (push) to get closer to PRO ones and be open to learn from them.

I vote for these as well:

  • LMB select - I like the idea to get rid of border select (B-key) and use LMB drag combinations for it.
  • Click or drag on empty viewport to deselect.
  • CTRL+A

Well the last thing "unchain keymaps" actually can sum it all.
If hotkeys editor will have these or similar features,

  • unlimited customization
  • detect conflicts, duplications...
  • keep consistency button :)

presets can be created for anyone taste.

Anyway voting for better hotkeys :)

I second ASD think it's a great suggestion. As alm said ASD is in perfect distance from shift, ctrl, alt and still close to 1,2,3.

I think it would be a shame to just try to follow the "pro" packages instead of trying to create the most effective/easy to use mapping for blender

Hello, it is really great that you want change hotkeys. I am in 3D more than 10 years. I used 3dsmax, Maya, Softimage and now I am Blender user. I everytime used default hotkeys until I started use Softimage, because it has really bad hotkeys and same in Blender.

So I setted and tested my own and I am using it during last 5 years, maybe it will be some inspiration for you. It is not complete here, but if you want I can send more:

Some important things:

  1. It is really bad idea set hotkeys by name of commands. So for example G = Grab, R = Rotation, S = Scale ... it is good for learning, but very bad for effective using
  1. Don`t use SHIFT, CTRL, etc ... There is only few commands what you really need. So most of my hotkeys are simply one key. 1, 2, 3, V,
  1. If you use it often, it must be very close to your fingers.

In Maya, 3dsmax, Unity there is WER, in Sotftimage there is XCV, but for me best is: SDF as you can see in my picture. It has simple reason. F is marked on your keyboard so you can find it immediately without looking on the keyboard and you are still so close to SHIFT, CTRL etc.

Hard to to tell for me what the general preference is here but as a Unity, Unreal Engine 4 and C4D user, WER and alt+mouse for view is definitely my preference. C4D uses ERT and alt+mouse for view but you end up reconfiguring it.

The main reason is that WER with alt+mouse are used in a fair amount of popular software (Maya, Max, Unity, UE4, C4D) etc. and as such when using them together the context switching of a completely different map is annoying.

In the end as long as they can be remapped though its probably not the end of the worlds as a user can modify the tools to match their favourite uses. It just raises the concerns as before about tutorials. If for instance ASD are chosen then its highly likely that you will end up using WER for stuff that was probably gonna be on ASD so will make it harder to learn Blender watching tutorials when you have changed it to use WER.

Just my 2c for now, I have been a Blender watcher for a long time but am hoping to get more involved now (it was in fact this move to make LMB primary that has motivated me to have another go and I am really liking it now I have it configured with LMB, WER and alt+mouse for view) ;)

I think that ASD is fine just like WER. It will be great if we can create 2 "standard" keymaps by switching only ASD and WER keys, rest of keymap should be the same.

I think ASD is better because there is more accessibility to keys like shift and control. It also is easier to reach more keys because your fingers are in the middle of the key board..

With WER, your pinkie finger ends up on the useless caps lock key. That really doesn't help with making keys easy to get to.

Yes. Most of us agree on that. But there is no simple choice between ergonomy and user habits (from other softwares). Two similar standard keymaps would be great.

Suggest we stop discussing ASD vs. WER vs. ERT vs. ... for now, as it seems to be an endless discussion with the only result of a big wall of text without much helpful arguments. There isn't much interest in keeping such tasks open.
So let's not focus on such "unimportant" details for now and tackle the real issues, okay? :)

So one of the real issues for me is, that there is some hardcoded hotkeys. So if you want remap keys it can not be changed everywhere. For example N-panel has I for keyframe same for nodes.

Also I can not change hotkey for hair painting, If I want paint hair with ctrl + left mouse, I cant..

I hope this is in the right topic but a CMD/CTRL swap would be mighty nice for Mac users. so anything mapped to CTRL on Windows/Linux can use CMD instead.

This comment was removed by Andrei Nadin (AnadinX).
Albert (wevon) added a comment.EditedNov 6 2015, 11:19 PM

Although things are going in another direction, I make this entirely different proposition.
I believe that the SPACE bar is underused, it's a long key that lets slip your hand around the keyboard without losing sight of the key. We could use it to do combos with other keys in the same way that Ctrl or Alt.
"B" Key (= Blender) could replace the current role of space, "B" it is in the center of the keyboard too, and it's accessible with both hands.

Krita or Photoshop move the layout with the SPACE key, and ZBrush lets move curves and selections while you are creating.

With the hand on the center of the keyboard it is very comfortable to access to "G"," R"," S", current transform shortcuts; for this reason I would not change them.

This picture showns the convinations I would do with the middle mouse button, the other buttons could be used to do more selection convinations or float menus.

Other similar option.

Spacebar opens search_menu when is pressed.
If search_menu is opened on release**, Spacebar+MMB pressed could be used for moving the view (like Photoshop, Krita, Illustrator, Inkscape).

Doing this, Shift could be free for other purposes.
Maybe Spacebar+RMB could be Border Select,
and Spacebar+RMB could be used for Cursor position

Julian Eisel (Severin) changed the status of subtask T37520: Remove Hard-Coded Keymap Items from Unknown Status to Resolved.Sep 21 2016, 10:46 PM

Coming from 6 years of the incredibly easy to use Cinema 4D with its simple key commands, easy modifiers and vastly superior interface, Blender is far more complex than it needs to be. Looking at the key maps and modifiers and trying to keep a constant workflow feels like I went back to the stone age when in Blender. Why over complicate? Serves no practical purpose and hinders workflow. Can a person spend a ton of time and effort and become proficient in Blender? of course, but at the cost of efficiency and far greater time than what should be needed. For 7 years iv been hopping for Blender to get its interface and workflow in gear. C4D has the ability to customize the interface much the same way as Blender but the execution is better, and workflow smoother.

@West (Formula409) can you provide some specifics that're actionable? In the keymap revamp we're working to address many of these observations, but without specifics there's nothing we can really take away from your feedback other than it's difficult, which isn't particularly helpful.

By default Blender accepts the actions with the left button and cancels with the right. Some addons like Mira accept with the right button, and others like Craver sometimes do it with Space.

Personally I think that accepting the actions with the right button is a good option as it allows you to continue editing with the left button. For example, when we move the same object three times with the manipulators, it perform three different actions when with a combined action would suffice. Another example, when we extrude, its only possible until the margin of the window and then pressing F6 we can continue, but if the left button would allowed to continue moving away the faces would be more visual, I think.

On the other hand, I think that Carver shows the modal options of the tools much clearer than as the default blender.

There are keyboard shortcuts that only work in one area and one mode, and there are others that always act, such as F12 to render or Ctrl + S to save.
I do not know if it would be a good idea to ban the general shortcuts and make all specific for the area and working mode. In other words, Ctrl + s should only act on the information area, for example.
I only comment as a reflection, as I think this might facilitate the editing and maintenance of the shortcuts.

0rAngE (undo) added a comment.EditedJan 22 2017, 8:55 AM

I have extensively customized Blender's interaction, and I feel I have a fairly good insight into the Input Editor ('Engine"), and also some minor insight of what might be happening under the hood.

I thought I would add my opinion in this thread.

I think the main issue with the keymap in Blender to date is not necessarily it's 'uniqueness' only. But the fact that once that uniqueness forces you to find/create an alternative, the Input Editor is not really developed as a smart tool, and makes it a super hard task. This is where most people give up. Some adopt the defaults, but most move on.

To summarize, I think it's not (only) about what should be the default keymap, or available presets. Because one will never be able to make everyone happy. Rather it's about creating the best environment for artists to create their own setups!!!

These are the main issues with the Input Editor I feel need to be addressed first in order to allow for any kind of success with the new keymap.

  • When a new operator is created or existing remapped, there is no prompt of created conflicts.
  • Creating new operators relies on python commands, those often are hard to track down. An alternative route would be to have all available commands present, order the same way as in the application menus (consistency) where one would just assign/delete a key. Having python commands is good! But having it as the only/default option is not an optimal design choice.

While we're on consistency and menus, rRMB Menu by PLyczkowski is an impeccable prototype of how to organize Blender's menus.

  • There is no 'Smart Tool'-esque consolidation
    • Navigation should be set at only one place globally for the application!!! This would be then used in all editors 3D and 2D
    • The most obvious one: Select and Box Select. These should be merged and set as a single operator. All the other modifiers (Deselect, Add to Selection, etc) should be nested under this main Select entry. This will reduce clutter overall ind improve customization as everything related will be grouped under one entry.
    • Operators like 3D Manipulator "view3d.manipulator" should have the "Planar Constraint" as part of that operator's sub keymap. Meaning beside the check box should be the spot to setup the hotkey for the planar constraint. In cases like this it's pretty safe to assume everyone wants this behaviour as part of the tool! And it's safe to place SHIFT as the default state. It is confusing for new blender users (and anyone creating a custom setup) to go through theses kinds of things.
    • All shared commands throughout the Editors (like for instance 3DView>Mesh and Image>UVEditor) Should have only one global operator. If you feel the need to have the option to individually customize, you can have a check box beside that operator to expose individual customization. If so, this should be a local setting on the level of the operator and not a global setting. It's cool to have all windows/editors modal, but having it as the only option creates more issues than it solves.
    • Consistency! Example, Operator to scrub timeline is not under 'Timeline' group, it's under 'Animation'. This is confusing! (hence one of the things some were asking about my setup 'Can you scrub the timeline with the LMB?'

Why don't things like this change when you swap out LMB <> RMB button in UserPrefs>Input>SelectWith:Left/Right? This is all, I feel, the biproduct of the 'unique' design choice that was made initially. The design is so rigid and inconsistent that it can not be just swapped!!! This is also the main reason why this new keymap has been such a drag to rectify. It all leads back to the RMB paradigm that introduces many more serious issues than the ones it tries to resolve.

  • It is very confusing in InputEditor>Operator>TypeOfEventMapping:Mouse >TypeOfEvent (dropdown): to have avalable LMB; MMB; RMB; Action; Select. This on top of having Mose and Tweak. Tweak in my opinion is a sub event of Mouse.


Those are just some of the issues. My point is, in my opinion, the main effort should be invested into creating a smart Input Editor, accompanied with more smart tools within Blender.


I can be reached for additional feedback if desired.

Albert (wevon) added a comment.EditedFeb 10 2017, 10:19 PM

A couple of small suggestions:
When you want to move an object in Z and Y is pressed G + (Shift + X), I think it would be more comfortable to use G + X + X.
With Ctrl + LMB, selections are made with lasso, it would be more useful to do it with Shift + LMB, adding + Alt to execute the rectangular selection and + Ctrl to invert the selection function.

I can share my point of view from Modo user perspective.
I primarily use wacom tablet to work in Modo.
Alt + LMB - viewport rotation.
Alt + Shift + LMB - pan viewprot.
Alt + Ctrl + LMB(drag sideways horisontally) - zoom.
Select with LMB - paint selection is by default - you just drag your cursor over the model and paint selection - very handy for wacom tablet. In blender you have to press C and it is worse.
dragging RMB activates lasso selection(you can change it to rectangle selection in the preferences if you are the mouse user. I prefer lasso, because it is super handy with wacom). This selection affects only visible polygons(facing you) in the shaded mode, and all polygons(even turned bacwards to you) in wireframe mode.
dragging MMB on the empty space activates same functionality, but now it selects everything, that went under the lasso.
Ctrl + LMB - deny selection
Shift + LMB - add to selection(if you completed first click. On wacom click can be very long, until you complete the stroke)
RMB - single click = context menu.

Also modo understands the sequence of selection - I select two polygons in the row and hitting Up arrow will continue to select next polygons in the same pattern. (If I skip one or two polygons between two selected polygons - up arrow will continue to select polygons with the same skipping pattern. Very handy.

w - move
e - rotate
r - scale

After we have pressed W E or R if we press Ctrl + Shift + moving gizmo - we dublicating the surface and moving/scaling/rotating it, instead of original selected one.

Gizmo can be moved by simple LMB click in the viewport when W/E/R tool is activated.

There are many more interesting decisions in modo. I've just started to learn Blender and do not know much about it, but, at the moment - working with tablet is worse than in modo. Right click selection is very bad idea.

There were various Blender keymap changes in 2.8 to improve consistency, with no major further changes planned.

For bigger changes, the industry standard keymap is still under development: T54963

Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.Oct 31 2018, 2:44 PM
Brecht Van Lommel (brecht) changed the status of subtask T37420: Default Keymap: Review and/or Rework Selection from Unknown Status to Unknown Status.Oct 31 2018, 2:47 PM