Default Keymap: Revamp #37417
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
38 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37417
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
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.
Proposal
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:
Scope
Keymaps are difficult and complex. Initially this keymap will address Selection Tools for all editors(#37420) 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, @JonathanWilliamson, 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.
Changed status to: 'Open'
Added subscribers: @JonathanWilliamson, @brecht
Added subscriber: @cessen
Some other general notes about this:
@cessen made a keymap proposal . Perhaps it's better to get into the specifics of the key mappings in subtasks, but the principles listed there seem quite sound to me, so we could figure out here if we all agree on them.
Added subscriber: @PawelLyczkowski-1
While creating the keymap, it would be good to check if it's possible to:
@PawelLyczkowski-1 I agree that we need each of those things. But I vote that we hold off on those until the keymap refresh is done. The keymap refresh can be done without any additional development, and so it's quite feasible to do alongside all the other 2.7 work.
Although, I do agree that a Press and Hold option is needed and could help with the new keymap. @brecht, what do you think?
The other two items I vote we wait for 2.71+
I agree, the keymap editor itself can be much improved, but that's mostly of an orthogonal task that I do not want to make the keymap revamp depend on. If a developer likes to tackle that topic at any time, great, and we can help with reviewing code and design. But right now we focus on design tasks that do not take too much developer time or that developers are volunteering to work on.
Regrading Press and Hold, I don't have an opinion at the moment, need a better understanding of what this is supposed to do in practical examples and how that fits in the operator design.
@brecht, two examples for Press and Hold:
Pie menu like functionality, allowing user to hold a key for a menu or action and then release to confirm
Easier assignment for modal operators, allowing modal to be activated during the press, and then confirmed upon release
1 is particularly valuable for a mode switching menu.
2 is already doable with specific modals, such as the View3D Gesture Circle, Gesture Border, etc, but it's not extendable to other items.
Ok, so this is kind of making "Confirm on Release" into a feature you can have for all modal operators? It seems reasonable and might provide a solution to the messy situation there now, but I would need to think about it a lot harder to say for sure if this is the right way to do it. But the general idea of having an easy way to configure one behavior or the other in a keymap I agree with.
Added subscriber: @billrey
This is a really nice todo. I'm in favour of going in the direction that Cessen has outlined.
As for 'press and hold' (ala 'sticky keys' in XSI) is really useful. It can enable really fast interactions. Consider it also for hotkeys for tools.
Here's an example for Grab: Imaging holding down G, moving the mouse, then letting go of G to confirm the placement. It becomes almost like a gesture.
@billrey that's a great example of how this would be useful. Much better example than mine. Makes for great tweak controls.
@JonathanWilliamson
Major development, sure. But I have frequently run into issues that have to be addressed in Blender's C code while working on my experimental keymap.
The latest issue, for example, is that you cannot currently customize what key is used for inserting keys in the properties panel and n-panel. It's hard-coded as "i".
IMO one of the benefits of creating a new keymap is that we can help sort those kinds of things out, and help make sure that everything really is customizable for other keymaps as well.
@cessen good catch. I've added a subtask to start listing these keys out. They should definitely be moved to the python keymap whenever possible.
Added subscriber: @liquidape
Added subscriber: @Lockal
Added subscriber: @BartekSkorupa
Added subscriber: @BartekMoniewski
Revamp Default Keymapto Default Keymap: RevampAdded subscriber: @JoseMariaRichardsonRebellodeAndrade
@billrey I don't think that would work well, since for rotation, for example, double tap "R" makes it rotate in Trackball mode. In my opinion, it doesn't apply well to G, R and S.
A place where it would apply well would be
Mode Switching. Hitting "Tab" could remain Mode toggling, but holding "Tab" would bring up a menu with all the Modes. A pie menu would be even quicker, because you'd know, lets suppose, weight paint is always up, vertex paint is always diagonal up and right, etc,... and you would just do it mechanically. This way it would resolve the Mode Toggling mess, and keep the current functionality untouched.@brecht In case it still isn't clear to you why holding key option would be good, check out the first few seconds of this video, which shows how it works in Maya. It works very well and fast. We could use this, but with a better logic behind the actual keys used.
Video: Holding down Space bar ≠ Tapping Space bar
Hey.
I've been working on a proposal for the keymap revamp for the last week. I've had experience in a few 3D packages, and I currently teach 3D animation at a University in Portugal, so I thought I could try and help. Hope it helps:
Josemaria RRA's keymap proposal for 2.7
Added subscriber: @xrg
Added subscriber: @DataDay
Added subscriber: @dennyrahadian
Added subscriber: @ionarn
Added subscriber: @Luarvik
Added subscriber: @Januz
Added subscriber: @zeauro
Josemaria, I like the idea to use F12 instead of P to load game engine.
It was not be a good idea when we used game engine for rigid bodies animations.
Now, we have rigid bodies without BGE.
Maybe an animator using game engine for IA animation registering would have a different feeling.
Do you have an idea for Select Linked ? Ctrl L is to use to extend existing selection. But L is used to select linked geometry under mouse cursor.
I did several remarks about Default Keymap in pie-menus discussion that I should post it.
First of all, I would like that it tries to take into consideration azerty keyboard.
For instance, shortcuts using "." could be replaced by ";" . It can be weird for qwerty users but "." is absolutely not functional for azerty users.
If people against that are numerous, I think that it would be cool to bundle an azerty version of default keymap.
Pie menus will use Q for view navigation.
I think that our problems of obscure hotkey combinations like Shift Ctrl Alt C, Shift Ctrl Alt M, Shift Ctrl Alt F could be solved by using Q and P as modifiers.
It works also for an azerty keyboard. And a dvorak variant could be bundled with a replacement of P by V.
If in the future, we have an implementation of pie-menus using sub-pie-menus. it will be necessary to use a single key for these pie-menus giving access to more than 8 items.
In this case, current single keys would have to be remapped to double keys. And if we already use things like Shift Ctrl Alt C, it is because there is no single key available and really few double keys still unused.
";" would be a problem for american spanish keyboards (since it's shift+,). We may be getting ahead of ourselves though, selection and pie menus need to be worked out first so the new default keymap can implement those changes.
Added subscriber: @RobertoRoch
Added subscriber: @TARDISMaker-2
Added subscriber: @DoctorShenanigan
Added subscriber: @michaelknubben
Added subscriber: @wevon-2
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.
@PawelLyczkowski-1
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-2 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
Altworks like a "negative" modifier (alt+g, alt+s, alt+i, etc.). Editor generic shortcuts could be inCtrl, like ctrl+up, ctrl+z, ctrl+s, ctrl+q, etc.Count me in for a proto.
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.
Added subscriber: @OskarSwierad
Good refactor :) Holding keys would be reealy cool. That's how they dealt with complexity in mobile OSes.
Proposition: - [x] for Item selection mode. like - [x], but not additive. Super useful when you have many rocks or something combined into single meshes for optimization (eg for games).
@OskarSwierad Select Linked could definitely be done better. More ideas about how to refactor selection can be found here - https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit#heading=h.v3pmlvpgvk9o (Select Linked is double click there, with shift to add and ctrl to remove).
@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.
@PawelLyczkowski-1 - 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.
@BartekMoniewski 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. @Januz proposed nice thing about modifier keys. This must first be applied to selection. Then we can build rest on top of that.
Removed subscriber: @OskarSwierad
@BartekMoniewski 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.
@BartekMoniewski 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 @BartekMoniewski's example wasn't a problem. As @PawelLyczkowski-1 states, it's clearly not empty space.
Added subscriber: @ZsoltStefan
@michaelknubben:
The question is, how faris 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.
@PawelLyczkowski-1: 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.
@ZsoltStefan
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:
Removed subscriber: @cessen
Added subscriber: @cessen
@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:
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).
@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.
@PawelLyczkowski-1
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).
@PawelLyczkowski-1
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:
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.
Maya:
Max:
XSI:
Houdini:
Cinema 4D:
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.
@PawelLyczkowski-1
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
It also occurs to me: your point about WASD from gaming is actually an argument in favor of @PawelLyczkowski-1's ASD suggestion, not WER. ASD and WASD share the same resting hand position, whereas WER is both up and over from that.
@cessen
I respectfully disagree with that assertion. First a couple of points:
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.
@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.
Added subscriber: @btolputt
@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.
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.
@PawelLyczkowski-1
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.)
Added subscriber: @ideasman42
@cessen
That sounds awesome. But it's less related to the keymap, and more related to how the operator works. Talk to @ideasman42 maybe?
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:
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.
@PawelLyczkowski-1
So, is what you mean something like:
tap "x" = delete context-sensitive
hold "x" = delete menu appears
?
@cessen
I really like holding key for the manipulator. Sounds really clean.
@JoseMariaRichardsonRebellodeAndrade Correct.
Added subscriber: @koilz
Just a picture for how I would rearrange the keys, mainly for edit mode.
I like GRS.
Added subscriber: @ygtsvtr
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.
A S D F = Face 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.
This comment was removed by @BartekMoniewski
Added subscriber: @MikhailRachinskiy
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.
Added subscriber: @Takanu
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:
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 @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.
Added subscriber: @TomasDostal
I would like to share my opinion as former MAX user and current MAYA and BLENDER user.
I have 3 suggestions (wishes):
WER vs. ASD, or any other combination:
I have few reasons to vote for WER keys:
PACKAGES
3DSMAX
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 :)
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:
Well the last thing "unchain keymaps" actually can sum it all.
If hotkeys editor will have these or similar features,
presets can be created for anyone taste.
Anyway voting for better hotkeys :)
Added subscriber: @phelioz
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
Added subscriber: @Cenda
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:
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
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,
If you use it often, it must be very close to your fingers.
PS:
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.
Added subscriber: @AnadinX
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.
Added subscriber: @JulianEisel
Moderation
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 @AnadinX
Added subscriber: @ManuJarvinen
Added subscriber: @JasonSchleifer
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
Added subscriber: @Formula409
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.
@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.
Hello,
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.
Added subscriber: @0rAngE
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.
...
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.
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.
Added subscriber: @ACap99
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: #54963
Changed status from 'Open' to: 'Archived'