From BlenderWiki
This is a wikipage for discussing and developing a new keymap for Blender. When we say "keymap" we are also referring to input devices in general (perhaps "input map"). However, the focus of the project is keyboard and mouse.
Overview
Motivation
A great deal of things about Blender were improved with the 2.5 project, but the keymap is still more-or-less the same as it was in the 2.4x days. The keymap has built up over the years, with new functionality being crammed into the ever dwindling unused hotkey combinations in a somewhat haphazard way. The result is a keymap that, while capable, isn't nearly as efficient as it could be.
Goal
Our goal is to create an updated keymap for Blender that is consistent with current typical Blender usage patterns and feature sets, to increase workflow efficiency and usability.
Principles
Some basic guiding principles to keep in mind while developing a new keymap.
Principle 0
No principle is sacred. Including this one. Every rule has a time and place to be broken, and we shouldn't be dogmatic about things. We should instead be practical and have real user experience guide things.
Principle 1
One thing that Blender's keymap already does well is consistency across different areas and modes of Blender. The quintessential example of this is the G, R, and S hot keys for grabbing, rotating, and scaling selections. No matter what part of Blender you are using, if those concepts apply at all, then those hot keys are what you use to do them.
That kind of consistency helps users switch between different areas and modes of Blender without having to think about it. I think this is very important, and we should seek to preserve and even expand upon this.
Principle 2
Most-used functionality should have prime real-estate on the keyboard. The more often a tool is used, the less acceptable it is for its hotkey to involve five modifier keys, three repeat key presses, and a complex mouse gesture. Ideally the most-used functionality of Blender should be a single key-press away.
Principle 3
Hand-strain is bad. Hotkey combinations that are uncomfortable for the human hand should be avoided.
Principle 4
Confusion is bad. Hotkey/mouse/whatever combinations that frequently cause confusion should be avoided.
A good example of this are the current hot keys for object mode switching. I've been using Blender for years, and I've been doing serious rigging ever since BBB, and I _still_ get confused switching between object/edit/pose mode with armatures ("I'm in pose mode right now... if I hit tab, will that take me into edit mode, or exit into object mode...? Okay, it put me in edit mode. What if I hit tab now? Will it take me back to pose mode, or exit into object mode...? Gah!").
Principle 5
Consistency with other software. Tautology: unless there are good reasons to not adhere to an existing ubiquitous UI standard, then there is no good reason to not adhere to an existing ubiquitous UI standard.
We can deal with this on a case-by-case basis. There are plenty of cases where there are good reasons to be different. But in some cases there aren't. In the latter cases, we should pull from existing standards to avoid unneccesary mental "mode switching" when users switch between Blender and other software (including, e.g., their operating system).
This also applies to not changing things in the keymap just for the sake of changing them. We should try to be consistent with Blender's old keymap where reasonable as well.
Principle 6
Muscle memory. The more the keymap can take advantage of people's muscle memory to speed up workflow, the better.
Principle 7
For common OS's (Windows, OSX, popular linux desktop environments) we should seek to avoid hotkey conflicts. For example, we should probably avoid using ctrl-alt-delete as a hotkey, due to Windows. And OSX makes heavy use of the function keys for OS functions.
Related to this is differences in keyboard layouts. Laptops, dvorak, localization, etc.
It is not at all obvious to me how to deal with all of this. We don't want to end up with the least-common-denominator, because that would be very limiting. But at the same time, we don't want to keep people from using Blender, or make their experience bad, simply because they don't have the "approved" keyboard layout.
Also: number of mouse buttons? People using tablets? Etc.
Ideas
Key Logging
From Douglas E Knapp:
A basic idea is to find what is used most often and then make those keys the most easy to type, remembering the rule of one hand on the mouse at all times. Finding the most used commands might be done by writing a recorder that is mode aware and then letting a large group of pros/advanced users use it. Once you get the data then you have a great starting place when it comes to deciding what is important and often used VS commands that are almost never used.
Mode Switching
Some observations:
- Mode switching in Blender is currently a pain. The "toggle" mentality for mode switching worked fine when there were only two modes for objects. But now that e.g. meshes have up to 7 modes, this paradigm is no longer viable.
- Users should never be at a loss for "Where am I; how do I switch out of this mode?"
Proposal: Make the spacebar the "context" key, for mode switching etc. Whenever a user is confused about where they are mode-wise, they can press spacebar and at least switch to a mode they know.
In other areas of Blender where there aren't "modes" per say, the spacebar still manages "context", e.g. "Where you are." For example, in the sequence editor it would be the key used to manage going into and out of metastrips. In areas of blender that do not have multiple modes or context, the spacebar will do nothing.
What we consider to be "modes" and "context" is admittedly going to be a bit fuzzy. This can crystallize as we test it with actual usage.
Sub-modes
Some modes in Blender can be conceptualized as also having "sub-modes". An example of this is mesh edit mode, where we can also switch between vertex, edge, and face display. Whether we should actually consider this as different modes or not, and how we should map them to hotkeys, is an open question.
One possibility is to treat them as top-level modes. Then instead of edit mode, we have vertex mode, edge mode, and face mode for meshes. These would then be accessed via the same method as the other modes. This would require some core code changes, however, since even if hotkeys treated them like modes, things like e.g. the mode menu in the 3d view header would not list them as such.
Another possibility is to treat them more like sub-modes or display modes, and give them their own hotkeys within edit mode. This could also be useful, since they could be given single key-stroke hotkeys, which is important because switching between vert/edge/face display while modeling is frequent and needs to be very fast. Perhaps vert/edge/face simply becomes 1/2/3 on the number row.
Redundancy
Going through Blender's existing keymap, I've noticed that there is an enormous amount of redundancy. Some if this may still make sense (e.g. x and del both acting as "delete"). But most of it is purposeless, and simply a result of Blender's keymap evolution. Weeding out these redundant hotkeys should be a priority.
Left Mouse-button Select
It seems like it's high time for Blender to join the rest of the world on this. The new keymap should use LMB for select throughout Blender.
This is also a matter of self-consistency, as right now Blender uses RMB for select in some places (3d view, fcurves editor) and LMB for select in other places (outliner, text editor). This should be unified even if we don't switch to LMB-select.
This may be tricky in some cases, though (from the mailing list):
> The only mess-up I'm aware of is weight-painting mode. > Trying to select a new bone just paints. Hmm. Yeah, this may be trickier than I thought. Also consider selecting faces/vertices for masking. For people using mice, switching painting functionality to RMB will work fine. But for tablet users it's important for LMB to be paint, since that's the one with pressure sensitivity.
Keymap
Quiting
- Quit: Ctrl-Q
Search
- Operator Search Menu: Tab
Major Mode Switching / Context
- Switch Mode/Context: Spacebar
Saving
- Save Blend File: Ctrl-S
- Save-as Blend File: Ctrl-Shift-S
- Save User File: Ctrl-U
Loading
- Open Blend File: Ctrl-O
- Append From Blend File: Ctrl-Shift-O
- Link From Blend File: Ctrl-Alt-O
- New File/Load User File: Ctrl-N
Selecting (except for text editor / fields)
- Single Select: LMB-click
- Single Select Add: Shift-LMB-click
- Single Select Remove: Ctrl-LMB-click
- Box Select: ???
- Lasso Select: ???
- Paint/Circle Select: ???
- Pan: LMB-drag
- Zoom: Ctrl-LMB-drag (up=zoom out, down=zoom in)
- Orbit: Shift-LMB-drag
