Blender 2.8 Blender Keymap changes #55162
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
73 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#55162
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?
(NOTE) This is an ongoing topic, design is not final
(NOTE) Update: We recently added the ability to detect drag events separately from regular key-presses, so we now have the ability to use pie-menus as a secondary input method for keyboard events. For this reason, we are experimenting with reinstating the Tab key for mode switching, so that pressing Tab works as before. However, holding Tab while dragging enables a pie menu for mode-switching. This exact configuration is experimental, but committed for further testing in the Blender Studio. We may apply this approach to other hotkeys too later on.
In Blender 2.8, we want to make some changes to the default keymap. The goal is not to do a complete overhaul of the Blender keymap, but rather to identify specific problems and then solve them. Blender 2.8 will require some amount of relearning, so now is a good time to address some of the keymap issues we have.
Current State (testing)
For now this shows the new keymap for people who want to use 2.8
The list of changes which have been applied is maintained here: #55194
Previous State (Blender Version
cfc4805455)lots of information is interesting, but content is not matching current Blender 2.8 state.
Issues
Specifically, we want to address these issues:
Changes
With the above problems in mind, here’s how we are thinking of changing the default keymap in Blender 2.8:
Switch Modes: Ctrl-Tab + Pie menu
We want to keep using the Tab key for mode switching, but make it more consistent and better suited to switch quickly to any mode. We do this by keeping the old tab-to-editmode behavior, but also making it so you can hold Tab and drag to spawn a pie menu with all the modes available. Pie menus can be very quick to use, because you can simply flick using a gesture while holding Tab.
Switch Collections: Dash (-)
For Collection (layer) switching, we can no longer use the number keys as we did in the past, because of the fact that users can have an arbitrary amount of Collections, and because they can be nested.
However, we still want to enable a quick way to switch between them using a keyboard-centric workflow, like so:
Users can hit the dash key, which opens a menu of Collections under the mouse cursor. They can then simply click each Collection to set it to Local View, hiding all the other collections.
Also, these Collections are dynamically assigned a hotkey, which becomes active and visible when this menu is open. If Collections are nested, users can hit two number keys in a row to jump to nested collections.
Operator Search: F3 (Cmd-F on OSX)
This can make the Operator Search feature more consistent, so it’s always one keystroke away.
Switch Tools: Space
Makes switching the active tool very easy and accessible. It can become context sensitive to fit with the mode and editor.
Applications where a tool system is the only way to access functionality often bind these tools to keys.
Blender already has a fast, keyboard oriented workflow, which we don't want to drop at the expense of introducing a tool system.
On the other hand, a tool system does not have to be inefficient (if an add-on adds a useful tool to the toolbar, we should have a fast way to access it).
Using space as a modifier key allows the full set of keys to be used for tool access without conflicting with existing bindings.
Tools key bindings are set based on the keys used for immediate (non-tool) access.
This way pressing:
GgrabsSpace-Gsets the grab tool.... same for scale, rotate .. etc.
This way experienced users who are familiar with Blender's shortcuts can keep the toolbar hidden and occasionally access them via keys they already know.
Notes:
Enable specific Sculpt & Paint Tools: Various direct keyboard shortcuts
To make Blender more consistent, we want to the number rows to behave consistently. For this reason, we would like to remove the number keys to switch tools in paint and sculpt mode. However, there will still be ways to use hotkeys for switching tools, just not the number row keys. In Paint & Sculpt modes, the hotkeys will be displayed in the toolbar. Users can also use the space bar to get a quick menu and change tools this way.
Viewpoint Switching: Numpad numbers & Tilde (~) Pie Menu
This makes it more consistent, so that the number keys work in a consistent way, both for laptops and desktops.
Switch Workspaces: Ctrl+Tab (next) & Ctrl+Shift+Tab (previous)
With Blender 2.8, we are introducing workspaces. We want to make switching between them easy. We want to make it work like switching browser tabs.
Pivot Point: Period (.) to cycle though them. Hold period (.) to display pie menu with all pivot options
This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the period key to cycle through pivot options, or they can hold down period to display a pie menu for quick switching.
Orientation: Comma (,) to cycle though them. Hold comma (,) to display pie menu with all orientation options
This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the comma key to cycle through orientation options, or they can hold down comma to display a pie menu for quick switching.
Here’s a more concise overview of the changes:
Current Blender Keymap Inconsistencies
Anton Atnoguzin mailed us with a list of inconsistencies in Blender's current keymap. Here's a list:
Mac Keymap
We want to improve support for Mac keyboards in two ways:
Added subscribers: @WilliamReynish, @pablovazquez, @ideasman42
Added subscriber: @michaelknubben
Added subscriber: @L0Lock
Something pointed out on that RCS topic , is that the ESC key cancels a lot of things and, in some scenarios, can cancel several actions in one single keystroke (and most of the time it's not wanted). While a "solution" could be to make the Esc key cancels only the "active" action (if that is possible ?), I think that Esc key actions should be reduced at least for some elements.
I propose that ESC key should not be able to cancel any action or task which can be/is processed in background and/or have a specific stop/cancel button (or could have one) to stop it.
This includes :
Added subscriber: @AndrewPalmer
This sounds like a good start. For shortcuts that let the user cycle from an enum selection, such as the snap target, it might be good to show the user briefly via a small text popup somewhere near the cursor what the setting has been set to. For example, you could show "Pivot: Cursor" when the user presses the . key, and that text would change as they cycle through the options.
I hope you are planning on fixing some of the finger acrobatic shortcuts for common actions, such as ctrl+shift+c for moving the object origin (and tangentially, perhaps even make this work in edit mode). The menu that appears also has some overlap with the shift+s menu, so perhaps look into combining them if it makes sense.
Also, I suggest getting rid of ctrl+q to quit blender, since it's used at most once per session, can be hit accidentally quite easily (ctrl+a is close), and is a duplicate of alt+f4 anyway.
Added subscriber: @Traverso
You should consider changing the Workspace switching shortcut to Ctrl +Tab (next) and Ctrl + Shift +Tab (previous). It is what all web browsers use for tab switching.
Added subscriber: @mendio
@WilliamReynish, I really like the idea of changing modes with numbers, but please note that in Grease Pencil we have an extra mode: Draw
Andrew: Yes, ideally we should do something like that.
Marek: Yes, was a mistake
Matias: Yes, for sure. This example was for Mesh objects. For Grease Pencil, the list would have to be slightly different. Ideally, we would make it consistent though, so that Edit Mode & Sculpt Mode uses the same hotkeys both for Mesh and Grease Pencil objects.
Added subscriber: @Rawalanche
Looks really good. I know this is not the industry standard keymap, but I would still suggest to shuffle it around a little so that 1 2 and 3 keys do Vertex, Edge and Face edit modes respectively. There are quite a few Blender users who have set it up that way, and it's just much more common. I do understand the reasoning of the current proposal though, as having object mode at 4 feels a bit random.
I personally would suggest object mode being on the tilde key. This would just mean viewport pie menu has to go somewhere else. Q key is free in the default keymap as far as I know. Or it could perhaps go on some modifier key+mouse button. Alt+MMB? or Shift+RMB? Something like that. Both of these are free in the default keymap AFAIK :)
Added subscriber: @jpthrash
Totally agree with rawalanche, 1-Vertex, 2-Edge, 3-Face, 4-Object, 5-Sculpt... feels more natural imo.
Added subscriber: @dark999
Tilde or ~ is not the first character of pressure on most of the non-English keyboard as an Italian keyboard. The user who uses nationalized keyboards must also be considered when choosing shortcuts IMHO
Added subscriber: @0o00o0oo
I use quick layer changing a lot more often than mode change, so making the number change modes isn't ideal for me, and presume would be true for a lot of Blender users as well.
I came from Maya, but that was one of the features I immediately took to, and it'd be a shame to get rid of it altogether.
Are there plans to still allow for quick changing layers through hotkeys? Not all layers, but at least being able to quickly go through some of the layers would be nice.
Added subscriber: @YAFU
Hi.
I think that for key numbers to be intuitive, they have to follow the order of how Modes appear in the Modes selector menu. So if that is the order that modes will appear in menu in 2.8, I agree with William's proposal.
Anyway, I think that assigning keys to each Vertex/Edge/Face selection mode in Edit mode breaks the intuitiveness a bit and makes remembering keys a little harder. I would include only Edit mode in "2" key. Then "3" key to Sculpt mode and so on.
For particular Vertex/Edge/Face Edit modes quick selection, I can not think of many ideas for now. Perhaps being in Edit Mode, with each press of "2" key it can quickly change between Vertex/Edge/Face select modes successively.
Added subscriber: @renderhjs
Something to also consider is the UV image editor:
For the shortcuts 2,3,4 (vertex, edge and face mode) it would be nice if these were mirrored in the UV image editor and potentially using 5 for selecting UV island / element mode.
Regarding number keys for modes.
Also...
Why not having the different modes (Object/Edit,Sculpt,WeightPaint...) in the Function keys F1-F12? and keep Mesh-Select modes (Vert,Edge,Face) in the number keys and maybe numbers 5-9 for certain overlay/shading standards? One is only gonna switch between modes every now and then while Mesh-Select mode change is more often accessed, same goes for shading/overlays. This is obviously my biased opinion as a modeler.
Having vertex/edge/face on 1 2 3 is very important due to how incredibly frequent action is switching between these. It's no coincidence that it's one of the most common key mappings to be seen in other software. In fact, current way Blender's mesh element switching is implemented harms modeling speed and efficiency significantly. Just watch any Blender modeling video on YouTube and you will realize how frequent action it is. It certainly deserves those keys.
Regarding consistency with other editors - yes. It is absolutely crucial that 1 2 3 vertex/edge/face selection is consistent for example in UV editor. It would make no sense otherwise. It needs to accommodate for muscle memory.
As for Tab for search, it is a prominent key, but search is a prominent feature. + Tab is generally used for search in CG software, such as Maya or Nuke.
Lastly, if Object Mode was moved to tilde, as I proposed above, then both Pose Mode and GPencil edit mode can fit onto 1 to 0 keys.
EDIT: To accommodate for Tilde key not being left of the 1 key on some exotic keyboard layout, we could have one setting on the left property panel of the Input tab which would allow you to redefine which keyboard key gets registered in the place of tilde. So if you had for example Italian keyboard, you could just click this button, press a key that's left of the 1 key on your exotic keyboard, and then such key would be registered for all the functions mapped to tilde key. :) We already have "Emulate numpad keys" feature, which is similar type of feature, so it could be grouped into some "Layout emulation" group of input settings.
Added subscriber: @ManuelGrad
@Rawalanche the number of users using an "exotic keyboard layout" might be bigger than you think. The german keyboard layout for example also doesn't have a tilde key ... probably the largest userbase of Blender sits in Europe (and Germany/Austria/Switzerland/Italy is a big chunck of that - and these countries are probably not the only ones with an "exotic layout"). I agree, you will never succeed in making something that everybody is happy with so i'm good with going the way of the mayority, but i think it's worth investigating this further and see how many people are affected by this.
@Rawalanche, not having vert/edge/face accessible from number keys doesn't mean access is necessarily slow/inefficient. Of course these should be quick to access. As with UV/particle modes which have equivalent settings.
@ManuelGrad
Well if you see EDIT section of my last post, you will see I am actually not dismissing exotic keyboard layouts, but instead proposing a solution that would make such keymap work even with the exotic layout. The way you formulate your reply sounds like I am dismissing exotic keyboard layouts, which I am not.
I also have not said you can not make everyone happy, so I am not sure what you are agreeing with. In fact I think it's easily possible to make at least vast majority of people happy with solutions properly iterated based on user feedback.
@ideasman42
Well, switching vert/edge/face modes is really so frequent action when modeling, that it's important for it to:
1, Be assigned on 1st level hotkey. No modifier key combination
2, Be assigned to a hotkey that's not far from natural hand's resting position.
3, Be assigned to a hotkey that doesn't interfere with any other hotkey used in object mode or modeling.
4, Take only one step to do, just one keypress. Current form where you have to do 3 steps (Hotkey+Modifier key, then move mouse to a desired choice, then click) is way too cumbersome for such a frequent action.
5, Be assigned to a set of keys that are next to each other for easy memorization.
I don't think there are many options left other than 1 2 3 keys which would fulfill all the 5 requirements listed above.
@Rawalanche sorry, it wasn't my intention to suggest you're dissmissing exotic keyboard layouts. I just wanted to say that the number of users that would have to change the new proposed default would probably be pretty high. And the thing with defaults is that probably 95% of the people tend to stick with it. So they won't have a button for Object Mode. How many countries are affected by this? How many keyboard layouts are commonly used all over the world that don't have that key on that position? I don't know the answer. Does the Blender Foundation have statistics where the users are coming from?
If carefuly you read my proposal in the EDIT paragraph, about an option in the input editor to re-define which keyboard button Blender interprets as tilde key, do you disagree with that? Do you think it is a bad solution? Do you think it would not resolve this issue with different keys in place of the tilde key?
Just so options are considered.
I use right-click drag options for vertex/edge/face mode change. Drag up for edge, left for vertex, down for face.
Carried over from Maya days and it's ridiculously fast once learned. Has the added benefit of not having to take left hand off current keys.
Since pie menus will be default in 2.8, maybe this should be considered. That way, 1,2,3 can be freed up for still other modes.
@Rawalanche No, i get that, and yeah - it is a solution! But if a large number of users have to change the new default then it's not a good default imo. Also i do believe most people won't change the defaults at all.
Added subscriber: @thornydre
Instead of cycling through the submodes by clicking multiple times on a particular number key (that is what I understand from the design), would it be possible to have a pie menu when holding this number key, so for example if I click on 2, edit mode shows up, and if I hold 2, a pie menu with vertex/edge/face mode shows up ?
We discussed the number keys and decided to simplify it, so that the number keys simply reflect the main mode selector. This way, the order can be the same and be mirrored both in the mode selector and in the number keys. Other modes also have submodes and we want to make this work in a consistent way.
Same for the T panel, that was proposed in the last Blender Today live, holding T could show the tools under the cursor (spacebar at the moment)
Note: the mode list is incomplete:
Is it intended not to have pose mode accessible?
I'm lost, Grease Pencil is an editor or not? GP needed an editor shortcut ?
Added subscriber: @xrg
Several years ago, Nathan Vegdahl was working on a new keymap. I don't know how relevant it is now, but figured I'd throw it out there. Might have some ideas worth stealing.
Here are a few videos he made about it:
https://www.youtube.com/watch?v=PaB7r_Q47qk
https://www.youtube.com/watch?v=Heyl8bCv9r4
This is actually very smart, good idea. Only thing that I am a bit worried about is that people tend to jump inside and outside edit mode quite often. This solution means to jump for example directly into face selection mode, you have to perform two actions instead of one. But I guess that's not as big of a deal, as entering and exiting object mode is not as frequent as switching the actual mesh modes once you are in the edit mode.. What's important is that actual mesh element modes will now have easy access through a direct, one step hotkey :)
Just to make sure I am understanding this correctly; By mode selectors, you mean these, correct?
i still lost, if i press 4 enter in "Texture Paint Mode", press 4 again and i enter in "Pose Mode" or i view "Texture Paint Mode Face Selection submodes" ?
Mmm, "Pose" Mode could be the last number not used so far. I'm not sure if that's 8 or 9, depending on whether Grease Pencil will be a mode too.
Or "Pose" Mode could also always be shown in Mode Menu, but grayed out when an armature is not selected (to continue with intuitivity with order in Menu). In the same way, if you are in Pose mode, grayed out not available modes in Modes Menu.
If you have an armature selected and press 4, you change to pose mode, if you have a geometry selected and press 4, you change to texture paint mode.
this makes sense, but if I select multiple objects like mesh and bone and press '4' what do I expect?
I guess the active object will be taken into account.
Just to clarify, Grease pencil in 2.8 will be an object as a mesh, curve, bone, etc. that has modes: Object mode - Edit Mode - Sculpt mode - weight Paint - Draw
is it OK, in the 3D view in object mode I add a new object 'Grease Pencill' and after? is not a specific editor necessary? What is the official name of the 'Grease Pencill' object editor?
Removed subscriber: @Traverso
Note that grease pencil branch has many more modes in the branch
greasepencil-objectSo we should probably re-use keys for mesh modes for grease pencil (the active object can define which mode is entered).
@dark99 , no, there is no special editor for Gpencil. It work as any other object in the 3d view.
@ideasman42 yes, it should share the same key as other objects for change between modes. The only extra mode that Gpencil have is Draw mode
Added subscriber: @ErickNyanduKabongo
I have bad feelings about to start to relearn key shortcut, not because i hate changes but because it will slow down artists/users. Blender is a tool, you learn to use it and make something awesome with it., but if every now and then you have relearn the way to use it, it is a slow down process for your creativity. Improvement should be made to relieve artists/users burden. Yes eventually many will learn the new way, and others not.
Numpad Numbers & Tilde Pie menu for Viewpoint Switching is this a combination or a two different options? Because tilde ~ is really difficult to reach in some keyboards, here we have a combo of 3 keys ( hold Alt Gr down, press tilde and then space bar)
Can we keep this on the discussion level and try not to make quick changes and encourage module member/owner to take part in the conversation? I have noticed some changes made in the other modes are not beneficial for the users.
Regarding using number keys to select submodes.
While it is elegant in some ways to press a key to enter the mode, then the same key again to select a sub-mode,
I think users muscle memory for each individual number key won't be all that accurate, meaning the user will have to be extra careful not to accidentally enter a different mode.
It also means you don't end up with muscle memory for quickly tapping the sub-mode key (since it moves about depending on your mode).
Suggest to use a single, more easily accessible key for sub-mode switching.
My original proposal for the other keymap, the industry standard one, had this covered. While there would be multiple keys to enter all the different modes, there would be just one global key to exit back to object mode, and pressing this key again would enter the last exited mode. So no matter which mode you are in, you always know you have this one "escape" key to get you back out of any mode into global object mode. At the same time, if you quickly need to jump back to the mode you were previously in, you don't need to think about which mode it was, and instead you just tap the same button again.
Regarding Mode Switching
How about using ctrl+tab to open a mode menu (similar to the vert, edge, face menu of edit mode) and also ctrl+tab to open the sub mode menu too (as it is now). Currently, ctrl+tab in object mode is assigned to weight paint mode, which feels extremely arbitrary, especially when you have other modes on keys that seem to reflect the name (v for vertex paint, for example). If you want to keep ctrl+tab for workspace switching, then maybe consider having the mode menus on shift+tab instead, but personally I quite like the current ctrl+left/right for workspace/template switching, and Blender bears little similarity to a web browser, so it doesn't necessarily make sense to use the same shortcuts.
Edit mode is toggled very frequently, so I suggest leaving it on tab, and treating it as a special mode, then users don't need to remember the mode they were in before in order to return to it. If it stays on tab, and you use ctrl+tab to switch modes or sub-modes, that feels pretty consistent and tab becomes the mode key. It's also not so different from the current layout.
Misc Points
I really think search should stay on a very easy to locate and press key, since it remembers the last operation, can be used to quickly repeat actions (just press space, then enter to call the last searched action), and it's very handy for finding operators not on a visible menu. It doesn't have to stay on space, and someone suggested ctrl+f, which is easy and makes sense, but search is amazingly useful for new users and long term users alike, so please keep it easily accessible.
Regarding tilde, I think it shouldn't be used at all, since as several people have pointed out, it's in weird places on many keyboards. I have a Japanese keyboard, and it's in the top right of the keyboard and requires you hold shift to get it. There is a language switching key where tilde exists on US and UK keyboards.
Finally, maybe think about leaving the numpad as a place for expanded shortcuts - things that can only be called from a popup menu on the main keyboard, but which users might want to access frequently and quickly. For instance, you might have a view menu that allows the user to select the camera direction that appears when a key on the keyboard is pressed, but you could leave the 1-9 keys functioning as they are on the numpad.
Added subscriber: @jenkm
It would be reasonable on macOS to change Ctrl to Cmd, since Cmd is main modifier key in macOS. It’s much easier to press Cmd than Ctrl, and there's no right-side Ctrl on the macbooks. Also Apple says avoid using the Ctrl key as a modifier, as it’s already used extensively throughout the system.
I like how the second press of - key switches to the Edge Slide. Similarly, for example, a second press of - can switch Scale to Shrink/Fatten or Push/Pull.
It would be nice to have hotkeys for quick toggle visibilty of Subdivision Surface modifier.
Also, currently there is a conflict between Control Point Row (Curve) and Repeat Last, both [Shift-R].
Yes, we should support the Cmd key for the Mac more consistently (we already use it for file level operations such as save, open, undo etc).
Subsurf will be handled in a new way for 2.8 to make better use of OpenSubdiv. This change has the side benefit of making it easier to support a hotkey to turn smoothing on/off
Added subscriber: @Ping
I have few questions about stupid keyboard layouts like the french one. While using 1 2 3 to switch mode makes sense, do we need on french keyboard to press shift? (numbers need a shift press on french keyboards). Same questions for the period for Pivot Switch or the tild for Viewpoint Switching (which even need "Alt Gr" key to be pressed). In other words, will the keymap be keyboard layout specific?
EDIT: I saw the part of the discussion talking about exotic layout but I didn't find an answer about keymap being keyboard layout specific...
Added subscriber: @BillySmith-1
First thing I do with a new Blender install is set
1=vert 2=edge 3=face
There is already a pie menu when you hold Tab to switch between all modes from any mode.
On what planet is assigning all of these modes to individual number keys less confusing than a single key and flick?
If you don't remember what direction to flick you still see it at a glance when the pie pops up and surely that's more intuitive to a beginner.
Absolutely love everything I've been seeing with 2.8 and enjoying watching it progress but this seems like some faulty logic.
Added subscriber: @Lberg
Hey guys. I think the numbers for the different modes maybe hard to get used to after years, but it s does make sense. it maybe hard but it s a good thing for me. But i m not really convinced with the workspace change ctrl tab. Why? Because when you pressed a popular shortcut like this in the past you could rest the mouse at the same point on the viewport and directly work on in another mode (like Edit Mode / Object Mode). When you change the complete screen it s no point in resting the mouse where it s at because your whole screen is changing anyway. And the buttons of the workspaces are in a calm and not so crouded place of the screen anyway. Up there there s not much other things going on than the workspaces. So it s not a big thing to go up with the mouse to the top click on a new workspace and go down with the mouse to a total different layout. There maybe cases in which it is handy to do it with a shortcut. When u need to change workspaces in a high frequence. But i m not sure if it should be "default".
Added subscriber: @AlexanderKolyasa
Yeah, I definitely don't understand you guys when you tell that vertex/edge/face is not so often used as the switching between sculpt-edit mode-GP and so on... How strange do you model?)))
Vertex-edge-face can be switched for like twenty times per minute. An it must be accessible as easy and quick as possible.
Maybe pie menu, maybe some other keys... but each of this modes must be acessible in single click for realy fast modelling
I just saw the new update video from @venomgfx . Kudos on all the update efforts to have a coherent and useful default keymap. I may not agree with all the changes, but I think it's a worthwhile pursuit.
I have one question though: Is there work on allowing better/easier customization of hotkeys & pie menus for 2.8?
A standard keymap is great, but I think we'll all agree that being able to actually customize fully is even better.
Pablo mentions in the video several times if you don't like the current setup, you can always change them, but that's not always the case as far as I know. For instance, axis, trackball rotate, and edge slide are not configurable (and I think there were a number of other ones). And if I wanted to, for example, add a custom edit mode change pie menu, I apparently can't do that without doing some semblance of coding.
Sorry if there's a task for this already, but I couldn't find any.
Added subscriber: @ldo
While you are at it, it would be good to have separate shortcuts for select-all and select-none. It gets annoying to keep having to think “let’s see, do I need to press
AKEYonce or twice?”.Added subscriber: @Rusculleda
Looking good! Im curious, if Comma will switch orientation, will there be a new shortcut involving the comma to set a custom transform orientation? Or will it remain ctrl+alt+space?
So screen layouts are now being called “workspaces”. What was wrong with the old shortcuts of CTRL-← and CTRL-→ to switch between them, and CTRL-↑ to toggle maximizing the current window/area?
Added subscriber: @khader-1
I like the shortcut changes! But can't we use tap to toggle between object "subdivision surface" levels and yeah .. when we do .. it goes through 3 levels of subdivs. Original sub1 sub2 .. and in the background it automatically creates the modifire for us?
I think this will be much appreciated by the community
Added subscriber: @LloydAlmeida
Nice Update on the Modes.
Shortcuts can always be changed not a big UX issue.
The bigger UX issue is stuff users cant change like the 3D cursor placement in Selection mode.
Can we please have Select none when clicking on a empty part of the screen in the Selection mode. Besides being the standard its logical.
Added subscriber: @DuarteRamos
Added subscriber: @wevon-2
Testing the new keyboard shortcuts, I see that in the Edit Mode menu, apart from with v, e, f you can access vertices with 1, edge with 2, and faces with 3. This way you can access sub-modes with 21,22,23. It is fantastic, could it be indicated better? I was just going to suggest it, and when I tried it I have see it works.
Another issue, I have already mentioned it before and I will not insist more, but I think the space bar should move the camera, and combined with other keys show menus. In text editing programs you have both hands on the keyboard, and Ctrl works well for shortcuts, but artists usually work with one hand and use half a keyboard. With the big toe on the space bar you can make any combination and the hand is left on the keyboard, not cornered to the left.
Added subscriber: @AxelMening-4
In different mods hotkeys for pie menu is different. It is not comfortable.
I propose use F1-F10 for Switch Modes (or other hotkeys). And 1-0 for submodes and Tools.
Use F1 for object mode, F2 for edit mode etc. (or another kays). And use 1-0 for switching betwen submodes
without pie menu.sorry for my english
Another vote for using the function keys F1 - F12 for the main modes and 1-9 for the sub modes.
Without nesting or use of modifier keys these keys would be easy to learn for expierenced and new users of blender.
I also like the idea of introducing a pie mebu or simple menu for the 'A' select all key, instead of just a toggle behavior it could open a menu with select, deselct and perhaps toggle and invert? In it.
Added subscriber: @s12a
Updated keymap so weight-paint/pose share the same key - since using them in combination is very common and pose/texture paint have no reation.
Updated keymap so mode-switching numbers group paint modes.
Added subscriber: @antoniov
@WilliamReynish I'm working in the grease pencil brach to use the keys 2, 3, 5 and 6 to enable the corresponding grease pencil modes if the current object is GP.
I had to fix some conflicts we had in the branch with the new keymaps also.
Antonio: Great! As long as they are consistent with the regular Blender keys, that's good.
Added subscriber: @ninthjake
I think (Tab)bing in and out of edit mode should stay. Currently when pressing Tab you go from your active mode to Edit mode and pressing Tab again returns you to the previous mode you were in. That is good because no matter what mode you are in (Sculpt/Vertex paint/Weight paint/etc) you are most likely going to want to switch to edit mode to make some slight modifications to your mesh before hopping back into whatever mode you were in before.
So I would suggest that a single press (Tab) should put you in and out of edit mode (since it is the most commonly used mode) and pressing and holding Tab could invoke a pie menu with the other modes and sub-modes are selectable. That would keep everything related to mode switching to a single keypress and be nice and neat. No need to remember what arbitrary number goes to what mode and no confusion if you press the wrong number key.
The number keys should be kept mode-dependent because having 1, 2 and 3 keys mapped to Vertices, Edges and Face selection modes is saving users a ton of time and in Sculpt mode 1-0 is used to quickly select the most common brushes, etc.
Added subscriber: @JoshStrawbridge
i don't mind the number row being used for mode swapping as much as i thought i would given muscle memory.
as for differing opinion on another hotkey change...
spacebar to bring up active tool switching rather than the search feature is a hard no for me. it just feels entirely wrong.
i was alright with the double tap space for search but why in the world are you entirely moving a feature to a different key for a new feature when you also cleared out the old use of a perfectly adequate hotkey for the new job?
we've already got the tool shelf over there on the left. tab for that feels somewhat like a reach to the left.
(tab seems to be in the same place on most keyboards in all the languages i've seen) so it's sort of a bit like reaching for the tool shelf and blender users are probably used to hitting the tab button on the fly to change certain functionality. active tool switching is still a change in functionality.
as such using tab for active tool switching feels much more natural a change than using tab for search rather than edit mode. it also leaves search in the place it has become natural. needlessly changing hotkeys is bad.
no matter how i think of it i can't figure out any need to swap spacebar from search feature to active tool switching.
the only reasoning i can thing of for the change is because tab is no longer edit mode and your first thought wasn't to move the new functionality to the newly cleared hotkey while leaving the old one in place because you already "changed" the old search hotkey and were wondering more about if the double tap was good for it rather than if the new functionality should move somewhere else and search should go back to it's old hotkey.
for the love of pete, please swap tab and space hotkeys so the search is still space and the tab key is the active tool switching.
there's no need for this change in search's hotkey but there are some okay reasons for tab to be a better choice for active tool switching.
This can't be used to access tools via key-bindings.
Updated the text "Switch Tools: Space", while none of this depends on the key being space, space does feel nicer to use as a modifier compared with most other available keys.
Added subscriber: @zeauro
I think that it is very important to have a keymap configuration editor able to recognize all exotic characters.
I have an AZERTY french keyboard and during a long period blender was not able to use row of keys about numbers.
Because on that keyboard numbers are on same keys above signals like &é"'(-è_çà , you normally access to numbers by pressing shift.
I think that there is already an emulation, now in 2.79 to make it works for layers.
But when emulating numpad, these keys are no more usable for layers.
Problem of emulation may be that some keys will loose their use to other thing.
So, you need all keys available to be able to transfer use.
For example, I can not use some keys of my keyboard because Blender does not recognize these keys.
I can't use the ones at same place of brackets on a QWERTY keyboard and the two ones below.
Instead of brackets, I have circumflex and dollar. Below I have ù and * instead of ; and ,
Blender does not recognize < : ! too as valid proposals for a key because on QWERTY keyboard there are above coma , semi-colon and 1.
Period is above semi-colon on my keyboard but pressing shift semi-colon does not activate shortcut corresponding to Period.
In the contrary, because semi-colon is also in low row, in qwerty keyboard ; I can change shortcut using Period to Semi-colon.
So, there is no fear to have to provide access to all symbols. It will not interfere with shift combination.
To allow exotic users to use all keys of their keyboard, used symbols should not be reduced to those in lower row of keys on a QWERTY keyboard.
Half of Europe use an exotic keyboard (QWERTZ , AZERTY, FGGIOD,...) and each have its DVORAK variant.
So, in order to let community creates keymaps corresponding to these keyboards, any exotic character has to be recognized as a valid key.
@WilliamReynish in the description of the update activity, in particular 'Current Blender Keymap Inconsistencies' change hotkey for the group, still exists in 2.8? maybe Brecht will not be so happy to read this new update. I apologize if I misunderstood this table.
Seriously, if you try to make a very 'exotic' Apple keyboard comfortable, you need to try and make comfortable using any 'nationalized' PC keyboard
peace
i know it can't be used to swap the active tool via a key binding.
i'm just saying swapping the active tool is already very readily available thanks to it being there.
not all hotkeys are created equal and not everything requires as much need for a hotkey as something else.
the issue i have is just that if you already know what tool you're going to use why are you going to swap the active tool via two hotkeys to use said tool with a mouse click rather than just activate the tool via a single hotkey?
are you thinking that people are going to constantly swap the active tool rather than set it up as a commonly used tool or a somewhat commonly used one with a harder to reach hotkey?
constantly swapping the active tool is going to slow you down vs just tapping the hotkey for a different tool.
i don't believe this active tool swap via hotkey will be used as much as you're setting it up to be. (still a good feature just maybe not worth changing an old hotkey for)
for people who have learned the shortcuts already, constantly swapping the active tool will slow them down even if they do that via hotkey.
they're more likely to set the active tool to something they use quite a lot for that given part of their overall workflow (or just in general) and leave it there to further quicken their workflow rather than slow themselves down by constantly swapping the active tool just to use the mouse button for everything.
if they find they more commonly use different tools for different parts of their workflow then it's still quite easy and quick to swap via click on the toolshelf or tab > hotkey but that's still a standard change based on a smaller task change within a workflow rather than a frequent change of the active tool in the middle of a task. it would happen at a time many users would likely forgive there not being a hotkey for it or just a somewhat less comfortable hotkey for it.
after all, we were in and out of edit mode quite a lot using tab and that was always a time when we were moving to some other task even if temporarily. changing the active tool is likely to happen at similar times.
for new users who don't know the shortcuts, they'll still have to read through the popup menu to pick the one they want.
in which case they're still having to aim the mouse after finding the one they want or before tapping the specific hotkey for it.
this makes clicking on the tool shelf that's already there in it's standard order and placement much more likely to become more ingrained in their muscle memory.
the result is that they'll learn the general area on the tool shelf to start moving towards before actually finding the tool in the list for accurate targeting of the specific tool.
the pop up changes place each time so with it they have to find the specific tool they want before really starting to move towards it which would make it less comfortable to use than the tool shelf.
again, i also feel that tab is a more natural transition for this kind of change in function because it was previously also used as a change in function on top of tab being on the same side of the keyboard as the tool shelf is on the screen giving somewhat of a visual connection to the reach left for tab.
i think spacebar as search also feels more natural a choice since spacebar is very commonly used when typing and you have to type to use the search function. it also benefits from that being the previous hotkey and muscle memory for old users is already there.
active tool swapping probably won't be used so much that it warrants the need for being a little more comfortable as a hotkey.
tab for active tool swap should be a little easier to learn, spacebar for search won't have to be relearned.
as such i don't think the benefits that active tool swapping has of space being somewhat more comfortable than tab for it's hotkey outweigh the what users benefit from not having to retrain their muscle memory from space for search.
i also think your view of the change may have been a little skewed because you may have somewhat burned into yourself that the new active tool swap functionality is on space before you changed the edit mode key but while you've been working in 2.8 i've still been actively using 2.79 and just checking out 2.8 builds.
i don't really have that intermediate step you took on the change of the spacebar before you had the change in tab.
i didn't mind the change from tab to 2 (and other number row keys) near as much as i thought i would but that change from spacebar to tab was terrible.
simply swapping the two tab and spacebar hotkeys with each other made it SO much more usable and easily adjusted to for me coming from normal 2.79 usage to 2.8 with these new hotkeys for everything else.
Added subscriber: @ZigiZen
Everybody focuses on mode switching and forgets that number keys are base workflow for any mode that uses brushes. Sculpting, texture/weight painting will be crippled!
Right now there's an addon called 1234select for edit mode that asigns 1 to verts, 2 to edges, 3 to faces, 4 to limit selection to visible. Install it, work with it for 5 minutes and then try to live without it.
Pie menu solves mode switching beautifully and for someone that only cares about object/edit mode needs only tab to switch.
In my opinion number keys are super comfortable to use and should be assigned to actions that are performed constantly, changing modes is simply a waste.
Added subscriber: @Bleke-1
The emulate numpad may not be ideal, but I'm using it anyway because, well, the numpad is on the wrong side of the keyboard. I hope it won't be removed permanently.
Pablo mentioned in his video that there is a solution for users of numpad emulation, but he didn't say what it is. So I'm here to ask how to enter edit mode while using emulate numpad.
I was thinking about too little shortcuts that might be useful :
Added subscriber: @moisessalvador
How about removing Ctrl+U as save start-up file? I've accidentally overwritten the startup file many times because of it, destroying my carefully crafted file.
Removed subscriber: @moisessalvador
Added subscriber: @orustammanapov
IMHO reassigning spacebar is a bad decision, spacebar should be used for most frequently used operations. Having it assigned as it is now isn't a big improvement. Since we have manipulators single key shortcuts (e.g. G,R,S) could be used to switch between tools.
Hi.
In blenderartists forum some users were worried about the difficulty to easily access/configure Wireframe mode so that it looks like 2.7. I know Wireframe is still WIP and maybe there will be better shortcuts. But from that I thought that since there are several configuration combinations for Shading and Overlays, it would be good to reserve a set of keyboard keys where the user could easily save their preferred Shading and Overlays "Current" configuration (Save current Shading and Overlays settings to a Key). I do not know if this is something similar to what was intended for "Q" Quick Menu (favorite commands).
Yes - viewport presets is something we considered, but decided against for now, in favour of a more direct system. We think that Workspaces can act as a type of viewport preset.
Re the Z-key behaviour, that's intentional. From the start, 2.8 was designed to eschew Wireframe mode as a necessary feature to work in 3D. That's why we've replaced the Z key to enable see-through X-ray mode instead.
Wireframes can still be seen in Edit Mode, and enabled anywhere via the Wireframe overlay option.
To make viewport settings quicker to set, we could perhaps add a shortcut to open the Overlays popover.
Added subscriber: @jeacom
I just want to point that changing Tab to search menu will be eventualy confusing for longtime users because everyone is used with it beind assigned to toggle edit mode.
It will be quite hard to adapt and remember to use the number keys.
A popup menu with all avaliable modes assigned to Tab would be better just like Cntrl + Tab for selection modes, and we could use the number keys to control wireframe and overlay stuff!
Added subscriber: @JulianEisel
I'm a bit skeptical about using the number keys for mode changing too. When changing a mode, users also typically change the task they are doing (object mode is an exception). That is exactly what workspaces should handle though - each workspace would have it's own mode set, e.g. the "Animation" workspace would be in pose mode, the "Retopo" workspace would be in edit mode with necessary tools, add-ons and viewport settings loaded. See #55246 & #53389.
So in the big picture, the workspace mode and multi-object editing would mean users switch modes far less frequent. Instead they would change workspaces. They'd probably still regularly toggle between Object Mode and the workspace mode.
So instead of using the number keys for selecting modes, I'd keep just a single key for toggling between Object Mode and the workspace mode. The number keys can then be used for other things, e.g. component selection (Vertices, Edges, Faces) in Edit mode, brush selection in paint modes, etc.
Since this is a big picture design that seems worth testing, why don't we try this first before aiming for a more conservative approach that assumes modes will be used like before 2.8?
I would be skeptical about not being conservative instead.
I will make a simple analogy.
Imagine the fictional world keyboard authority decide that the current QWERTY layout is old and hard to learn and decide that only ABCD layouts should be produced in order to speedup the new learners. You dont like the change because your brain already is trained so you think "Okay I can just keep my old keyboard" you do it for years until your keyboard finally break. You dont find any QWERTY keyboard on stores anymore. So you leave the work, stop teatching and go find another job.
Thats basically why we still use QWERTY keyboards since before eletronic computers.
It is a natural human behavior, once learned, they resist unatural changes, resist re-learning and when they are fored to, generaly things dont turn so well.
Added subscriber: @AlbertoVelazquez
Ah, well, if someone decides that wireframe mode isn't necessary....
Added subscriber: @DotBow
Will be very consistent to swap Y and C for axis switch ([Z, X, Y] to [Z, X, C]). All in a row!
It is like using 1, 2, 3 for modes and selection.
Y is too far from X and Z on keyboard and C is only for rare circle selection tool.
Have anyone tryied to undo (Cntrl + Z) on a paper and realized "Oh geez, thats reality"?
I think I discovered how I can adapt my brain to these changes.
Looks like I will have to keep in mind that The 2.8 is not Blender anymore, blender is dead!, I will have to unistall Blender in order to install "The 2.8". Otherwize I will keep pressing Tab, Tab, Tab to change modes because that's what learned blender is on my brain.
The hard part is that "The 2.8" has a lot of similarities with Blender so is inevitable to get confused, just like when you accidentally type Javascript syntax on a Python Script and vice versa.
Can someone change the default gray theme and replace suzanne with a teapot so will be easy to see that Two Point Eight is not Blender?
i still disagree with space being used for active tool swapping. to me it still very much seems like a needless change to move search off of space.
i've heard that the reasoning is that space can be used as a modifier i still fail to see the great reasoning for taking search off of space.
if space is changed to work as a modifier... what happens to shift+space? how does space do anything on it's own if it's a modifier? where are you moving the hotkey for the popup active tool menu?
is this functionality not just how you've already set up the various popup menus to work rather than some key being used as a modifier?
if in edit mode and i hit w+d will it not duplicate through the menu even though w is not a modifier?
how exactly do tool with shortcuts that have modifiers already on them work out with your "as a modifier" excuse? i mean i can't swap the active tool to spin with space+alt+r rather than space > alt+r.
say we move active tool menu to tab. will i not also still be able to press tab+s to change the active tool to scale? (the answer is yes, i tried it. blender's got some great and fast acting menus)
why does me changing active swapping to tab and then holding tab and pressing r as in (tab+r) function exactly the same way as if tab were a modifier?
is it because the popup is set up with hotkeys available and it's just quickly activating the popup then the popup menu item assigned to that hotkey?
so in that case isn't it not acting as a modifier but just doing it's standard pop up menu thing.
are you somehow changing space to a modifier key in the future and have yet to do that?
that is the only way i can see this reasoning of space being used as a modifier actually working out.
in which case what are you going to assign the active tool popup menu to since modifiers do nothing on their own?
it smells like bull poop excuses to justify a terrible choice to needlessly move a hotkey because it makes the hotkeys for a fancy new feature a little tiny bit more comfortable.
not trying to be a jerk. you're getting enough pointless crap from other people.
just saying prove me wrong plz or just own the choice without making excuses for it.
both are more respectable than what i feel we've been getting in this particular case with the spacebar and search.
even if you just own the choice that's good for me because i won't have to worry about not being able to change my settings to search being back on spacebar later on because modifier keys can't do anything on their own and i'm not going to be constantly swapping my active tool so i have no need for it to be ever so slightly more comfortable or extremely fast vs very fast already.
"Space bar to switch active tools conflicts with the Operator Search feature
It’s inconsistent if it’s double tap space some places, and single tap space in others
It makes Operator search slower to access if you have to press space twice."
it is a bit inconsistent to be space some places double space to another... why not figure out a good popup menu for those editors to have so it can be double space the whole way?
or we could stop ignoring that the "tab to edit" thought process for all of those may need to change to "2 for edit" which further frees tab to be THE PERFECT BUTTON FOR A NEW FEATURE like this while leaving search on space alone.
what does tab do in all those editors that don't need a active tool swap?
blender is used with a mouse and keyboard. it takes time to move your hand from your mouse to type in the search. double tap as a slowdown is still not slower than moving your hand from the mouse to the keyboard as such it doesn't matter that activation is slower. only people who type with just one hand would find this to be an issue.
I still inforce that we should make the search as a double tap on space, it's not slower at all (200ms slower maybe). And number keys for modes are wonky, easy to mispress the number row without looking at the keyboard.
Sorry the bad image manipulation.
The best bet for changing modes easily and explicitly is with a pie menu on Tab, just match similar modes on similar places, edit on top, object on bottom, sculpt (mesh and grease pencil) on right and weight paint/pose on left, less used modes on diagonals, so on, pie menus are perfect for that!
Number keys will be free for overlay presets that way!
And yeah, maybe overlay presets aren't a good idea.
Number row should be bound to collections and brush selection to make the workflow backwards compatible.
Brushes arent tools just like collections are datablocks.
Added subscriber: @AdamPreisler
Hello everyone:)
Regarding the Blender keymapping I have made some of my adjustments based on my workflow.I do a lot of hardsurface modelling so some of this might not be useful for everyone, but I am certain that many people would benefit from switching some of the default shortcuts to this.
Here is a rather WIP graphic explanation of some of the shortcuts (it also explains basic Blender shortcuts)
When I made this mapping I made sure that I kept classic Blender shortcuts but filled some space around them with useful ones that are so hard to press that people tend to not use them.
Here are some of my most important and useful remapped shortcuts:
I don't use NumPad (my hand is on the mouse) unless I need to input specific numerical values.
I have all view related keys mapped to keys 1, 2, 3, 4, 5, 6
1 is front view
Shift+1 is front view aligned to active object/face/edge/vert
2 is top view
Shift+2 is top view aligned to active object/face/edge/vert
3 is right view
Shift+3 is front view aligned to active object/face/edge/vert
4 is flip view 180 degrees around Z
5 is perspective/ortho and also I remapped Shift+F to Shift+5 (because it is basically walkable perspective so it relates to the persp/ortho switch)
It is useful to have everything at hand nicely. I also increased the lag when view changes to 700ms which makes it very natural as the brain can see the view change more gradually.
There are some Edit Mode shortcuts that I found to be a little bit too useful to not have closer to the left.
Like Alt+M which I'll get back to later but also Select Linked which is by default L.
The L key is actually fine for object management stuff like Ctrl+L and Shift+L but in the Edit mode... keys should be close together to avoid losing focus by moving hands...
So I mapped Select Linked to D
Deselect Linked to Ctrl+D
and Select Linked from Selection is Ctrl+Alt+D
The next thing I had to change is exactly as you noted all the enum mappings.
It was something like , . / ; ' or similar and while it is certainly useful to have keyboard mappings without Ctrl Alt and Shift it certainly gets messy when it's about a single thing that has different options and you map each option to a new individual unique key.
So What I did is I moved Pivot Point center for rotation/scaling shortcuts to:
Cursor is Q
Bounding Box is Shift+Q (more useful than Median Point I believe)
Active Element is Ctrl+Q
Individual Elements is Alt+Q
I often switch between these fast and many times even automatically (to make sure I use the correct one without even looking if it isn't in fact the one that is already have turned on). It gets fast when you get used to this.
and finally the object mode's super mega ultra useful Manipulate Object Center Points is Ctrl+Alt+Shift+Q
kind of related to Q is the W key which I mapped to Proportional editing toggle (default is O which is also too far from the left side of the keyboard)
W is turn proportional editing on
Shift+W is smooth vertex (should probably be on the mouse too.. dunno)
Alt+W is connected proportional editing (this makes me think Shift+W could be 2D projected proportional editing)
Another thing I changed is snap and it's shortcuts. Here I am not too sure about how well this one is picked but I am sure that I use it very often. It is usable both in Object and Edit modes.
Ctrl+S is snap cursor to activeand Shift+S is snap cursor to selected ...it adheres to the Q shortcuts - Ctrl is about active and Shift is basically about bounding box (kind of)
Related to this I also mapped Tilda key ` to be the Snap to menu (default is Shift+S?)
I found out after a while that I can map shortcuts of various combinations of Ctrl, Shift and Alt with the mouse buttons LMB and MMB (combinations with RMB are taken by special selections and quite rightly so, wouldn't touch that).
Well this enabled me to move the massively important Alt+M to Shift+LMB. You need to use the RMB for selection for this to work, but once you get how it works it's the fastest most intuitive solution to merging I know of, in any program. Please try it. I'm sure you'll like it:)
Later I decided to move the also important subdivide from W (specials menu, you still need to click on subdivide) to Alt+LMB (which is when you think about it from user's perspective, kind of an opposite to Merge - you create points)
Ctrl+LMB is taken by extrude and I left it at that but I remapped Ctrl+RollerUp to increase selection (by default I think it's Ctrl+NUM+ and Ctrl+RollerDown to decrease selection (default is Ctrl+NUM-)
What I also did here is I mapped Ctrl+Alt+MMB to change transform orientation as that can be very helpful and is rather hard to locate and select from by default. I use often View, Normal and Local modes.
Also very useful and formerly on the NUMPAD is the view roll horizontal and view roll vertical. Aka by default the NUM4 NUM6 and NUM2 NUM8 which I mapped to Shift+RollerUp and Shift+RollerDown and Alt+RollerUp and Alt+RollerDown.
Well and the last thing I changed is... I thought about the spacebar a lot. That is without a doubt the easiest a shortcut can get.
I came to the conclusion that it makes sense to have Space as "zoom to selected" it is easy to navigate through a scene without
getting your camera unmovable because you zoomed in too much without panning. Because zoom to selected moves the center of the
viewport camera's rotation (MMB). It helps to be like a spiderman in your blend file. Jumping from object to object and always focusing what you want and when you want.
Space = Space = Move to selected object in space(or selected points in the uv image editor, or selected keyframes or selected in outliner or .....)
Ctrl+Space = Control space = Dynamic Context Menu
Alt+Space = Alternative Space = remapped F6 shortcut to this (change last operator - very useful and well hidden for beginners)
Shift+Space = Shift Space = Focus on the Windowwhere the mouse is and maximize it... kept
Let me know what you think. I by no means think that all of these are great for everyone but from my years of teaching Blender I started teaching with my keyboard layout and many of these are much easier to remember and therefore to use for new users and also for me. Specifically the SpaceBar acts as a kind of home beacon when new users are lost in their scene and can't find a way to fix it. I just tell them to press A so that they have everything selected and then press Space which shows them their entire scene...
P.S. TAB is pretty great tbh so why not have it TAB+1 TAB+2 TAB+3 TAB+4 to be the different modes? I could certainly get used to that. But quite possibly TAB is not usable in conjuction with other keys unlike Ctrl Alt and Shift...
Oh my nono no, no! don't eschew Wireframe, please! That is one of my sanity tools in heavy complex architectural scenes.
Holding down [Alt] when you orbit the view with [MMB] allows you to snap to viewpoints. But this is impossible with Trackpad.
Some inconsistency in working without a mouse wheel:
Added subscriber: @MadMinstrel
Regarding mode switching, I'd just like to point out that Mode switching occurs frequently, yes, but definitely not so frequently that SIX precious prime real estate left side keys should be wasted on it. Just add a pie menu to the Tab key instead. Or just a plain old horizontal menu if pies aren't kosher for some reason. Instead, dedicate the number keys to whatever makes sense in a given mode. In Edit, that might be switching between submodes. In Sculpt, Texture Paint, Weight Paint, Vertex Paint that might be brushes. In Object mode they might be used for some of the newly-modal tools from the T-panel, like Cursor or Border select. Using all those keys just for mode switching would be a huge waste when the single old Tab key can do the job just fine on its own.
Also, put the collection switcher on the tilde rather then on dash, since it's pleasantly accessible on the left, and the "Show all layers" op the occupied it before doesn't make sense there anymore now that the number keys aren't layers. Just put a button for showing all collections in the popup collection switcher.
This design task ignores that we use the tab key as a way to edit data in other contexts, I think the changes were applied prematurely the design not thoroughly reviewed.
For example - you can't currently use "Operator Search" in the node editor if you have a node group selected.
I've made a patch which keeps this general intent of this proposal, while having consistent use of the Tab key for editing across NodeGroup/NLA/Action/Sequencer & 3D View.
See: D3465
Holly thanks @ideasman42 !!
Now we dont have motives to complaint.
But would be nice if there is a way to merge some headers and top bars to free vertical space, you know... Maybe optionally hiding the status bar...
Maybe making the workspace tabs only appear by hovering the mouse over.
Some people dont have displays the size of a wall...
+1 on everything you wrote, I really agreed with you, i tried to say something similar early about this changes. It seems like module owner are not taking part in the discussions. Thank @ideasman42 for listening to us.
not sure what patch notes you read.
search just gets farther out of reach with this, it's need for easy access is being undervalued.
spacebar is still defaulting ONLY to a new feature that's being overvalued as to it's need for epically fast activation vs just fast activation
double tap to search was perfectly fine and many of us didn't mind that. which means to fix the inconsistency there you'd just have to figure out a good menu to add to those other editors which would be more consistent overall than a prime hotkey that only functions in a single type of window.
reasoning as to why the other editor's use of tab should remain on tab is not there. no reasoning just feelings. take feelings out of it.
i don't see how 2 doesn't work just as well for these functions as tab does when 2 didn't do much in the other editors.
all i could find was that 2 changed the render slot in the image editor and it also functioned as a quick cut and camera swap for multicam strips in the video sequence editor. (new menu options for space before double space?)
i didn't even know about that second one but i found it by using user preferences > input and searching key bindings for 2.
both of these are context sensitive to either having the render result option selected in the image editor or having a multicam strip selected in the video sequence editor.
both uses of the number row keys would easily be carried over to shift+numbers or ctrl+numbers with minimal changes to their hotkey making the change easier to adjust to.
that being the case what justification is there for leaving these specific "tab to edit" functions on tab rather than moving them to 2 and keeping the long standing thought pattern that a single button will allow you to edit things in blender regardless of what editor you're in? breaking that thought pattern would be worse than simply changing hotkeys.
numberkeys for mode swapping works well. it does take some getting used to and as such is annoying right now but i can easily see how it'll be better in the long run.
also allowing edit mode to be on tab may appease people who are upset by the change but it's also going to be a crutch that will keep them from learning the new keys as quickly as quickly as they could while also muddying the waters of the changes that have been made.
all the other instances of 2 being used have easily carried over to the new active tool quick swaps in the 3d view for various modes. some might say they carry over better than the tools in object/edit mode purely because they already worked like active tools.
those other functions of tab in editors outside of the 3d view were likely on tab because of the "tab for edit" notion. this one button for edit thought pattern is not a notion that should be broken. it helped create consistency across the editors.
2 key is context sensitive after pressing it for edit mode. none of the other number keys are context sensitive for their modes.
you're missing a great chance there for some easy mode specific menus and/or editor specific menus/options.
the active tool swap menu is already context sensitive but then it's hotkey still only does things in the 3d view.
why not carry that context sensitive hotkey over to some other editor windows.
i know you people are smart but it does seem like you do some stupid things sometimes. (part of being human i guess)
the problem of the search operator not being available in other editors while certain things are selected is caused by moving it off of the spacebar or double spacebar hotkey.
going from "tab to edit" to "2 to edit" fixes that issue.
leaving search operator on double spacebar and adding some new menus fixes the issue but ruins the long standing thought process of a single key to edit.
this new solution muddies things up even worse.
moving active tool swap to tab still allows it very fast access via hotkeys,
going from "tab to edit" to "2 to edit" keeps a single button for edits and doesn't break that long standing thought process,
search on space means there are no new menus to be created for that to remain consistent across editors.
in truth i'd like to see search on double space with new quick option menus in other editors.
Just commenting.
There are a few frequently used operators that aren't exactly modal, so they doesn't fit on the switch tools context, but since they are so frequently used, they must be put somewhere visible,
they are:
What about search be activated by Enter when no other operator is active?
Added subscriber: @Januz
I've found a small problem with the new 1-2-3 mode scheme. If you enter edit mode with a text object you have no way out (using the keyboard). Pressing "1" only adds 1 to the text.
Use that new feature to the searchbar
And on sculpt mode and paint.
G > select grab brush
G + drag > pie menu with snake hook and grab brush.
F > Flatten brush
F + Drag > pie with Scrape and Flatten brush.
same for all stroke like modes..
This means you cant use it for convenient keyboard tool switching, try using it like a modifier: Space-G/R/S...etc are quick keys to switch tools.
With long hold this is no longer the case.
Update: we're testing using tab to toggle editmode as well as dragging for pie-menus: see
30cd35a37bAdded subscriber: @kebrus
I initially thought the changes to the number keys were actually good but the more I use them the more they feel like an afterthought.
There's something very weird happening at blender these days, it's like people are euphoric about bringing new changes but don't actually think them through, these are just some of the things I found with the new remappings:
Maybe I'm misunderstanding the use of the new operators but it seems to have overtaken blender design philosophy. While I actually think changing the space key is a good step forwards since is such a practical key, I agree with Josh when he says the operators are being overvalued. I get it, it's the new shiny thing, but seriously, isn't removing a vertical panel that served a multitude of purposes (more than it should) enough? You are forcing these operators onto people now. I already know I'm not gonna use them so fine, I guess I'm gonna get some space now, but now even a key is compromised? Like I said, I have no issues with using space key for something more useful but now we have a secondary way to activate these operators which only exist for new users to blend in better with the interface. If someone doesn't want to use them what is the issue of pressing T to open the tool panel if/when you actually want it? why the redundancy? Right now the tool panel is already a gigantic waste of screen space because it's mostly empty, do we also need to waste another key with it?
I feel that the issues here are bigger than which keys do what. I feel that something is at odds within the philosophy of the people working for blender. I've read a few pages when the design was starting and it seems no attention was given to the issues some of these changes bring even when they were mentioned. It's like the current philosophy is to do something/anything first and deal with problems later and I don't understand why not trying to prevent them.
EDIT: The previous post with might negate some of my points, it was posted while I was typing mine, so I'll leave everything intact anyway for information
the number row keys for mode switching were growing on me and i thought they were a good idea but i think i can work with the tab for edit mode and pie menu on mouse drag thing. it's not bad.
it still makes various modes easier to access and all but i'm thinking the need for an individual button for each mode switching would be greatly lessened if we could actually set up workspaces with specific modes selected for them.
if i want to set up a workspace for sculpting why should i still have to swap to sculpt mode rather than just change workspaces?
i'm sure most people will be glad to have tab back to something more like it's current use in 2.79- even if i'm not sure that i'm one of them.
i noticed you've put 1, 2, and 3 as vertex, edge, and face selection modes. should make that a little easier to swap between.
i'd rather see search being on double spacebar rather than f3 with some quick menus added for the various other editors so that it's consistently on double spacebar if that's the concern for it not remaining on the spacebar.
after all some quick menus for the other editors can only make things a little easier to use.
search is very useful for quick access to things that aren't so readily available. f3 doesn't feel as wrong as tab did for it but it's still farther out of the way than it should be IMO.
is there any chance at getting search back on double spacebar? there were plenty of us who really didn't mind that.
I thought that too, and I am not talking about code.
Some UI and Keymap changes seem like pop out of nowhere, without foundation or explanation.
"Lets take this and put there, remove that and hide on a menu, lets make a few more top bars and add tabs because chrome has them too, DONE! Now it look cool..."
First break blender in order to have things to fix?
More unnecessary work? That's kinda the opposite way to go isn't?
While workspaces for modes will be supported and useful at times, you may just want to switch modes without switching to a new viewport, navigating back to the same place... possibly having to adjust layer visibility setting the shading etc.
Artists in the studio didn't like double spacebar (also users online IIRC), AFAICS there was something jarring about a large popup showing before the thing you actually want to activate. While personally I don't mind this... I can understand why others might not like it.
There is some competition for easily accessible keys at the moment.
I would have preferred to make search the
Accent/Gravekey (above tab), which is now used for the view menu pie menu.There is no right answer here - this is a trade-off.
However view switching now has 3 prominent locations (AccentGrave / View-Manipulator / Numpad).
If we want we could use AccentGrave for search, and drag events for the view pie menu - patch: P720.
It may seem this way, however quite a bit of planning goes on internally including discussion with artists, event this task had many edits and changes before it was committed.
In retrospect we should have investigated the down-sides in our planning and factor that into the decision (make changes but accept there are trade-offs instead of overlooking them).
On the other hand - this is a development branch, we need some flexibility to try things and course-correct.
Update, discussed with @WilliamReynish and we agreed to use Accent/Grave for search.
During retopology i like to switch quickly to sculpt mode(pie menu FTW) to use smooth, grab or inflate brush to adjust vertices.
Sometimes I prefer grab brush than proportional editing, smooth brush rather than "vertex smooth".
During texture/vertex/weight paint I often jump to edit mode to select faces(for some reason in paint modes selecting vertex groups isn't available). Mode change combos are really powerful.
Pie menus for mode/view change(numpad keys to change view are workflow killer by themselves), number keys for brushes in sculpt, vertex/edge/face select in edit mode are base of my workflow and I can't imagine seamless work without them. Actually that's my main reason i like working in blender.
Added subscriber: @JonDoe286
You should be aware that is impossible to access Accent/Grave key easily in other keyboard that one with english layout
that's why i said "greatly lessened" rather than saying there would be no need. i actually had some blah blah blah about quick edits still needing it in there to start with but i'm trying to not be so long winded.
yea i had that thought before too. since i knew what it was i brushed it off. i've also had the same thought about activating the active tool swap quickly with the hotkeys. when you do that very quickly it just flashes up there and is gone.
even so, the new smaller menu that pops up now does help a lot with that. so it might be much less jarring to them than it was before.
if it's okay in this case because what you're activating is in the menu but double search isn't (i'm not sure what the difference is aside from previous menu size just having a jarring effect in general) wouldn't adding a search option to the spacebar menu change the thinking from "this menu with nothing to do with what i'm trying to do flashes on the screen" to "the menu i'm very quickly going through flashes on the screen."
which is basically the same effect as very quickly using the menu like it is now to change the active tool. it also has the benefit of letting new users more easily find search.
may seem inconsistent with being part of an active tool swap menu but if you change your thought from "this menu is for active tool swap" to "this menu is for enabling quick use of things" search still fits as an okay option and it also allows easier justification for adding menus to other editors... or heck add search to the active tool list. it'd make it easier to find for new users.
personally i'd like to see a menu in the node editor that would allow a quick selection of nodes to added in a string. maybe something context sensitive based on the previous node or selected node.
not really a predefined set but something faster than having to
shift+a, click, move, click. shift+a, click, move, click. shift+a, click, move, click. select all, f.
something more like
spacebar, click, click, click, enter/esc/left click off of menu/right click. then move them into position.
I agree and this is already reported and discussed
Tab for Object/Edit Mode Toggle + Mode Select Pie Menu
I would sincerely like to agree with "Piotr Adamowicz" on this. The key row 1-5 is much too precious in terms of Quick Accessibility that it almost seems like "Wasted Potential" to assign Mode Switching to them.
I do agree, being able to Quick Toggle between "Object/Edit Mode" is one of the BEST workflow decisions made in previous blender versions. But at the same time, I get why having them in 2 separate keys also makes sense. So you would not primarily need to switch back to object mode before switching to any another mode. Saves 1 extra keystroke. :)
At the same time, I think Toggling between "Object/Edit" mode should stay on Tab. It's "Extremely Accessible" and is 2nd nature to any blender artist/user who has been using the software for more than a week.
But also, if we could make it so that. Holding down "Tab" would open up a Mode Select Pie Menu. This just might solve the issue of easily being able to change modes when required.
I sincerely feel like 85% of the time we mostly only ever switch back 'n forth between Object/Edit modes. And maybe Sculpt mode when organic modeling. But other modes like Texture/Vertex/Weight Paint are so specialized that we just switch to one of those modes and stay in it, until we're done working in it. Rarely do we need to "Quick Switch" between any of those.
So being able to just select those 4 other modes (Sculpt, Texture/Vertex/Weight Paint) from a Pie Menu (which by no means is any slower once you get to using it) seems a more "Adequate" solution. And also having it on the same key as Object/Edit mode toggle makes things even faster. 1 Key to Rule Them All. :D
Example:
Tab (Tap) = Object/Edit Mode Toggle --- Tab (Hold) -or- (Hold + Drag Mouse?) = Mode Select Pie Menu --- Ctrl + Tab = Mode Select Pie Menu?
1-5/9 Keys for Context Sensitive/Mode Specific Shortcuts
Again I'd like to agree with Piotr on his suggestion to have Context Sensitive/Mode Specific Shortcuts on the 1-5 keys. It can even extend up to 1-9 if there is a need for it. (Sculpt Mode Brushes, Etc.)
Example:
Edit Mode (1-5) = Switch between component modes. (Vertex, Edge, Face, Etc.) --- Sculpt, Texture/Vertex/Weight Paint Modes (1-9) = Switch between Brushes, Etc.
Object Mode (1-9) = Frequently Used Tools from Toolbar? Although I feel it might be a bit redundant since we know the devs are working on a new Favorites Menu for Q. Maybe 1-9 can still work as a quick switch between Collections (when in Object Mode) if that's even possible with the new system. And if it doesn't become too confusing to use.
Search Should Be A Single Press Away
Now, about the Search function. After using it A Lot in 2.79 and with the new system in 2.80 experimental. I can firmly attest that "Search" is a function that should be A) Easily Accessible. B) 1 Keystroke Operation.
It doesn't matter if you're a Blender Veteran or a Newbie. Search function in Blender is the BEST I've ever had the privilege of using inside any creative app. It's just too useful & instantaneous to be discarded and hidden away in some hard to reach hotkey.
At the same time, from "My" experiences. I don't think you use it So Much that such a prominent key like Spacebar should be sacrificed for it. Don't get me wrong. I Love & Use the Search Function Everyday. But I don't think I use it so Frequently that I'd necessarily have it on my "Spacebar" key.
Now, That is extremely subjective. And I would never expect someone else to use certain keys the exact same way that I do. So depending on your usage patterns, Search might even be better on Spacebar for You. :)
As long as Search can be bound to a "Single Key". And I'm free to re-bind it to another key which wouldn't conflict with other functions. I'm Happy.
Personally, I switch views A Lot when modeling. So it easily makes sense for me to have my View Select Pie Menu mapped to Spacebar. It's the easiest to access for me while working fast. And I use it more than I use Search.
So here's how "I"would setup the hotkeys we've been debating about. *(Disclaimer: I'm in no way trying to enforce anything here. Just suggestingmy personal opinions + reasons behind how & why I'd use/setup certain keys.)*
Spacebar (Tap) = View Select Pie Menu
Ctrl + Spacebar = Toggle Quad View
Shift + Spacebar = Toggle Maximum Area
Ctrl + Shift + Spacebar = Toggle Fullscreen Area
Tab (Tap) = Object/Edit Mode Toggle
Tab (Hold) -or- Ctrl + Tab = Mode Select Pie Menu (Sculpt, Texture/Vertex/Weight Paint Modes) --- It can have a More (+) section if there are more modes than the usual 8.
1-5 (Edit Mode) = Component Select (Vertex, Edge, Face, Etc) --- Can easily use Shift + 1-5 to modify selection modes like we do now. (Vertex+Edge, Edge+Face, Vertex+Edge+Face, Etc.)
1-9 (Sculpt Mode) = Brush Select --- 1-5 would be ideal for most used brushes. But should still keep the current hotkeys for certain brushes. (Shift = Smooth, G = Grab, M = Mask, Etc.)
1-9 (Grease Pencil) = Brush Select
1-9 (Texture/Vertex/Weight Paint Mode) = Brush Select
~ Tilde (Tap) = Collection Switch Popup Menu --- Can maybe even work like Pie Menu Modals. When Collection Switch Popup Menu is on screen. Using 1-9 can quickly switch to whichever collection is indexed to that number. Just a thought?
(Alternatively) ~ Tilde (Tap) = Search --- Easily Accessible
Q = Favorites Menu?
These are just a few examples of how "I"plan to setup my hotkeys for 2.8. Having all my "View" related functions onSpacebar. Tab for quickly toggling between "Object/Edit" modes. Because that's just the BEST! :)
The only things I can't have at the moment are context sensitive/mode specific functions on 1-9. But if/when the devs add those functions into Blender. And I can customize it in the Input Settings. I'll definitely play around with it until it fits my workflow.
Floating Toolbar Menu
This is one of the new features which I'm still trying to wrap my head around in a usage stand point.
I understand the reason behind it. It's very Efficient while working, to have the toolbar popup right under your mouse pointer, rather than having to keep moving to the left side of the screen to click the toolbar icons or even search the keyboard & remember hotkeys. The latter being true especially for beginners or even for those of us who occasionally forget a hotkey. I'm one of those people. :) So trust me when I say, I don't want it gone.
But at the same time. I don't understand the reason for trying to force it on to the Spacebar key to be used as a modifier of sorts. Like, Hold Spacebar + G for Grab Tool.
Wouldn't it be easier to just hit G in the first place? Why even the need to hold Spacebar?
I'm not against the idea of having the Toolbar popup under the mouse pointer for quick access to tools, brushes, etc. And even the, Tap the corresponding key to activate the tool. Especially for people like me who work with the toolbar completely hidden.
But sacrificing Spacebar for it seems a bit Overkill for the lack of a better word.
Since T is already set to Toggle Toolbar why not use that? But with a dual function.
So, T (Tap) = Toolbar At Mouse Pointer, T (Hold) = Toggle Toolbar --- Because it's not something you do frequently. Or maybe it can even be reversed. T (Tap) = Toggle Toolbar, T (Hold) = Toolbar at Pointer?
Because either way, Spacebar is just too valuable of a key to waste on such a less relevant function. Some might use Spacebar for it's initial function of Search. And others like me would easily bind it to something even more workflow oriented like View Select Pie Menus, Etc.
Again, I love the idea of a hotkey to bring up the floating toolbar under the mouse pointer. I can imagine how helpful it is for a new user. And even for someone who occasionally forgets a hotkey and wants to access a tool quickly.
But let's be real. Even a new user will not keep using this feature for long. Once they realize they can just hit G = Grab, S = Scale, B = Box Select, C = Circle Select, Etc. They're just not going to bother Tapping/Holding Spacebar just to hit the same key. It's more Practical to just hit the respective hotkey and keep working. 1-Tap and You've Got Your Tool Ready.
Blender has been built in a very meaningful way that most of the time the hotkeys actually make sense. Like the examples I gave above. (G= Grab, S = Scale, R = Rotate, Etc.) So there really is no need to complicate or even make new functions that would only end up being a Virtual Crutch for new users learning.
For example, a Photoshop user might start out using the toolbar on the left and the small buttons on the panels. But the more they use certain tools. They start to realize, it's easier to use a hotkey for it. And then they start using B = Brush, C = Crop, V = Move, Etc. That's how true workflows are born.
You guys have been even more Awesome that you actually found a way to call the toolbar under the mouse pointer! I think that's way more than enough to get any new users started on the path to making their own workflows. :)
I do apologize for the extremely long post. This was my 1st ever post. I signed up today because I really wanted to follow and be a part of these discussions.
And I really hope we can all as a community have healthy discussions about these things and make Blender 2.8+ THE BEST DAMN BLENDER EVER!
THANK YOU Campbell, William and All You Awesome Devs Working on the Code Quest for all the immense amounts of hard work you've been putting into this project.
Thank You & Love from Sri Lanka. <3
Just gave the new commit a try. Damn, I'm in love with the new Click + Drag functions. You guys are Wizards. <3
Tab (Tap) = Edit Mode Toggle (Toggles from any mode you're in, into edit mode instantly. Love it!) A++
Tab + Cursor Drag = Mode Switching Pie Menu (THIS is exactly what I was talking about before. It's so Fluid & Quick and saves 1-5 keys for more useful functions. Mode Switching is still Accessible, Easy to Use & Fast!) A++
Accent/Grave (Tap) = Search (Also works well. Makes Search Accessible & Fast. Without being out of the way or difficult to press.) A++
Accent/Grave + Cursor Drag = View Select Pie Menu. (It works. Needs a little getting used to having Search & View Pie Menu on same key. --- Personally I might re-map the "View Pie Menu" function to Spacebar. So I can have all my view controls on Spacebar + Ctrl/Shift Modifiers. And save Tilde + Drag for something else. But that's just me. :)
Still, having View Pie Menu bound to such an accessible key like "Tilde" (Accent/Grave) + Cursor Drag seems like a perfect place to start. A+
1-3, Shift + 1-3 = Edit Mesh Vertex/Edge/Face. (You guys are on a roll. Remind us to send more candy bars when all this is done! <3) A++
Spacebar = Toolbar Modifier --- Again, I'm just that weird guy who will bind his view pie menu to it. So all good. :) A+
Seeing how Fast & Seamless the new Click + Cursor Drag Operation is. Opens up a lot of opportunities for quick action 'flick' pie menus and muti-function hotkeys. Awesome! A+++
A few mentions about the New - View Pie Menu
Really awesome that you guys added the "View Selected" to the "SE Corner". Definitely saves up a few clicks from the Official Pie Menu Addon. Here's how the previous one looks.
Notice, You've got to click on "More +" and then select "View Selected". I usually do "Spacebar to call the Pie, 3, 2 for View Selected". This new one really saves those extra clicks/keystrokes. :)
There are a few functions missing. But for the sake of keeping it Simple 'n Straightforward. It's pretty workable.
Some missing functions/workarounds,
View All --- Can hit Shift + C
Toggle Quad View --- Ctrl + Alt + Q (Ctrl + Spacebar in my case.)
Persp/Ortho --- Since Auto Perspective is "On" by Default. This too is a non-issue.
View Selected --- Conveniently placed by default on the main pie menu now. :)
Align Camera to View --- Don't think I use this much at all. But if needed can find it under the "View" menu.
All in all. Really streamlined implementation of the View Pie Menu into 2.8. Most used viewport commands, Easily Accessible. Would love to see the same treatment for all the other important pie menus and "Most Commonly Used" Functions & Tools.
Also a small request if I'm allowed to. Just a small visual thing. But I kept looking at the Mode Select drop down menu on the top left toolbar. And maybe my ocd kicked in. But it kinda felt nice if it was "Ordered" a little better.
The 3 Main Modes first. Edit Mode, Object Mode, Sculpt Mode. And the 3 Paint Modes sorted alphabetically. Texture Paint, Vertex Paint, Weight Paint. Something like this.
Hope it makes sense. :) Thanks Guys. Keep up the Amazing Work.
Currently, having search on tilde and view menu on hold tilde makes very little sense. Search and viewport switching are extremely different actions. Having them on same key doesn't make much sense.
Haha. Yeah. Does get a bit confusing. 1st thing I did once I launched the latest compiler was to move the view select pie to spacebar. Feels natural. Even Q can work I guess.
Gonna try and see if I can have Spacebar (Tap) for Toolbar and Spacebar + Click Drag Mouse for Viewport Pie. Hmmm. Should be a Win-Win then. :)
Edit: Just tried binding Spacebar + Click Drag for View Pie Menu. Doesn't seem to work while Toolbar is "Active/Bound" to Spacebar (Press)
Maybe it's because Toolbar can be activated and dragged around via mouse click + drag. So indirectly it's overwriting the Spacebar + Click Drag function if Pie Menu is bound to it.
Solution: If say, You'd want to use Spacebar + Drag for View Pie. Uncheck "Toolbar" operation -or- Bind it to a different key.
If you'd want to use Spacebar (Tap) for View Pie. Change View 3D Pie Menu hotkey to "Spacebar" and change action from "Click Drag" to "Press".
~ Tilde is also a "Dead key" with the US international keyboard layout, so its usage as proposed in Blender isn't ideal.
Tested, this should work in the latest build, for this to work properly we need to make our input system more advanced so it can take text input and use dead keys, or respond to hotkeys and use the scan-codes from physical keys.
Edit: this change was for Linux, we're going to need to review event handling and apply changes to each system.
This comment was removed by @JonDoe286
This comment was removed by @JonDoe286
Just tested last build and I like the tab drag thing for mode switching. It's IMHO better than using numbers. The edit mode is more accessible and other mode can be accessed fairly fast. Small bug, when Alt tabbing to another application and returning, the edit mode switch on :)
The new search hotkey is by contrast at weird location at least on a french keyboard and is not very easy to access (on french keyboard, it's "ù" not "~"). I liked the double tap on space better. I agree with rawalanche, having search and view switching on the same key doesn't seem very consistent...
Is there any plan to change the F keys usage? Those keys are very convinient and are pretty useless for now in my opinion.
Julien: which OS are you on? The problem you described has been fixed today, but only on Linux so far. On Linux, the Ù key should now work as if it was the tilde key, but this needs to be made to work on each OS.
confirm, the left button of - [x] under [esc] works perfectly in the Italian keyboard on linux. I see - [x] or if the SHIFT key is pressed - [x], with Blender it works as if I were pressing - [x] on the US keyboard
EDIT: it is only true with the linux virtual keyboard (KVKBD), not with the physical keyboard
Added subscriber: @LucianoMunoz
Im glad that you guys are revisiting all this and keep being open to input.
I think Tab back to modes is great, though i find that having 123 for the different components is a waste of keyboard, and should be grouped under one hotkey for the same reasons Tab for modes, they're all related to eachother and its better to learn just take hotkey with a mouse flick to also save space for more hotkeys to come.
For instance when it comes to the posemode with the breakdowner / relax / etc, it would be cool to tap the hotkey to activate the tool, but hold to get a pie menu and with this choose what's the one that you want to use. that would be neat. and i think its a methot that should work for several things, like for pivot point, tap the "." and jump back and forth between the two last used, but, hit and hold, get a pie menue to chose the one to change to.
same with transform orientation, and also with O for proportional editing, hit, turn on and off, hold, get a pie menu with the diverse options.
I could go on but you get the idea.
Yes, that's already what we are thinking too, to add pie menus to Pivot, Orientation and Proportional Edit.
that's lovely.
again thanks for all the amazing work guys!
Shade pie as well?
In addition to 1,2,3 for mesh element selection (a really wise move imo) what about adding a pie menu if you hold 1,2,3 with the most basic selection conversions for edit mode? something like this.
On top of this, Have you guys thought of using RMB for opening sub-object context menu? Like that we could free Ctrl+V, Ctrl+E and Ctrl+F.
On a portuguese keyboard the new search doesn't even work, we do have a tilde and accent grave key but it's a completely different one, it's next to the enter/return key. The key equivalent to the one you are using here is the backward slash or pipe key. However I didn't managed to use the hold and drag function even after setting it to another key, not sure if I need to change something else tho.
On another note, what about allowing tab to scroll throw elements like every other windows application? You already allow it in text fields, why not everything and make it consistent, why arrows?
Unless you are on Linux, the key isn’t expected to work yet, as it has to be added to Windows and Mac.
Don’t understand the second question about arrows and scrolling.
Paulo, maybe you use the same keyboard layout as mine. This is the type of keyboard sold in South America (Spanish / Portuguese):
https://i.blogs.es/a9ad78/cabecera/650_1200.png
Search function is in the key above Tab and to the left of "1" key. That key corresponds to (in spanish) "masculino y femenino indicador ordinal" and "barra invertida":
https://en.wikipedia.org/wiki/Ordinal_indicator
https://en.wikipedia.org/wiki/Backslash
I don't have an accent/grave key on my keyboard, It's a ptBR layout
I've set it to Return and works much better, IMO return is probably more intuitive since most games and software use it for typing commands and activate chat. Return > type > Return
I don't know if the probability of accidentally activating search is big but at least it will be almost universal on any OS or KB layout.
Also, experienced users don't like to use the Switch tools for sculpting and painting, it is a waste of time.
Now that the number keys are free for mode specific tasks like 1 2 3 for selection modes, could you bring back number keys for brush selection on sculpt and paint modes?
@ideasman42 What do you think?
Added subscriber: @Djay
Added subscriber: @Datross
On a french keyboard, the < ` > (accent/grave) key doesn't exist, you need to press < AltGr+7 > to get it, so I think whatever shortcut often used which is on this key isn't convenient at all (because blender doesn't handle modified key for shortcut).
The same applies with the < / > and < . > keys for which you need to press < shift + : > and < shift + ; >.
For the < ~ > case, if it's accessible through < ù > then there is no problem.
Added subscriber: @poffington
May I propose that if 1 ,2 ,3 is becoming Vert, Edge, Face select then we should also have the same system in the UV editor. Whatever the final solution is I just want to same hotkeys so I don't have to click buttons. Great work everyone
Given that a lot of people are missing the quick access to Search with the spacebar, and that the accent/grave key will be a problem in keyboards other than english, why not use the large empty space that now we have over the topbar and put there an easy accessible general search box? Search is really important feature to old and new users in Blender and this way it will be more visible and the users will not have to use any key to open it.
Reserve for brushes please!
Added subscriber: @wv0je
with "blender-2.80-be983295ea1-OSX-10.9-x86_64.zip"
on OSX Operator Search is now very hard to access (with a french keymap) ( In my opinion almost unusable):
with tilde : I have not been able to access
with F3 : ok bug very hard fn+F3 (Almost painful for the fingers)
with external it's very variable (something ok , sometime fully ko )
previouly (on older build we could use [£`]+ escape ... not anymore)
Does Blender need to go to multi-key sequences? E.g. in Emacs we have
CTRL-Xfollowed by one or more keys, alsoCTRL-Cis a prefix reserved for user-defined sequences. AndALT-Xis used to enter commands by typing their name.Not that I’m saying that Blender is the Emacs of CG software ... ;)
Added subscriber: @portnov
In 2.8, with the increased reliance on the Outliner, this would be a good opportunity to update the shortcuts there too. Problem is, manipulating items in the Outliner is inconvenient, because most of the basic shortcuts don't work there.
Currently, Del and X do nothing in the Outliner, making it rather inconvenient to remove items. We could also add Shift-D and Alt-D there to Duplicate Copy and Linked, respectively. We could even add shift+A to add new objects in there too, inside the selected Collection.
Adding new things is a sufficiently common operation that it deserves an unmodified keystroke, rather than something that requires more than one finger, as
SHIFT-Adoes.I notice that
INSis not defined for any purpose outside the Text Editor; how about using it for the Add function in the 3D Viewport?Inscould be added as well asShift-A, but not as a replacement. It's on the righthand side of the keyboard, so it's actually slower to access, and many keyboards (laptops, Macs etc) don't have this key at allThey must find it hard to toggle the overwrite mode in the text editor, then, since that operator is not bound to any other key.
I bet they would, if they wanted to use overwrite. Luckily, it's not an essential feature. Adding objects is.
What’s the current thinking on
accent-grave, then? Is it still on enable-all-layers/collections? None of the modified keystrokes seem to be used for anything.Ah, just noticed
ctrl-accent_gravein the Armature and Pose keymaps.By accent-grave, do you mean the Tilde key? It is used for viewport switching, but only works on Linux atm.
ACCENT_GRAVEis the name used in the RNA.Hi Guys, Was going through the new 'Minimal Keymap' and I'm really liking the changes so far. I know it's a process to Tweak 'n Perfect it, but seems like slowly we're getting there. :)
Also, I was trying to find a way to add the 'Set Origin' (Shift Ctrl Alt C) Popup menu to a hotkey in the new 'Minimal Keymap' preset. But I can't seem to find the command. It's a useful menu to have when modeling and moving stuff around so wanted to bind it. I found the list under Object -> Transform menu. But I can only add 1 of those commands at a time. Not a 'Popup menu panel' like before.
Set Origin Popup Menu
Set Origin Hotkey Command 2.7X
Set Origin Hotkey Command 2.8 Minimal
I'm a bit iffy when it comes to creating 'New' commands because in the past whenever I create a new hotkey command, it ends up messing something else up. For a noob like me, just changing the keybind and calling it a day seems to be the way. :)
Hoping that going forward editing hotkeys will become much more Interactive and Simpler/Streamlined. Having a 'Conflicting Keys Alert' would be Awesome too!
Thanks for all the hard work you guys. @ideasman42 You're a Machine Man! <3
Removed subscriber: @ZigiZen
Hi all.
About Tab+mouse drag: it is interesting feature, but it is very easy to enter this mode and accidentially select something by just accidentially touching a mouse (or think about touchpad) while pressing Tab to switch Object mode <-> Edit mode. So, can we have some sort of threshold? For example, enter "pie menu" mode only if Tab was held for at least 0.3 second (or whatever) AND mouse cursor was moved for at least 15px (or whatever). Otherwise, treat this event as just Tab press.
Separate keystrokes for unconditional-select-all versus unconditional-select-none -- Yes! Good idea.
Alternatively: is it possible for
AKEYto always mean “select all” whileAKEYtwice in quick succession always means “select none”? In other words, add new timing-based multi-keystroke behaviour, analogous to multiple mouse-button clicks? This would still get us away from the current toggle behaviour, while doing minimal violence to everybody’s existing muscle memory. (And open up a new vista of future keystroke options...)It appears that
CTRL-Wis still assigned towm.save_mainfile. Has everybody got used to typingCTRL-Sinstead? Can we reassignCTRL-Wto something else yet?For keyboards with a
~key, this works on other platforms too (US/English layouts, some other layouts too).If you're on win32/OSX and have a keyboard without a
~key, we don't yet support scan-codes on those systems.Forcing to wait will slow down peoples workflow (generally find it annoying),
If mixing drag and click events on the tab key is too error prone, I'd rather use a modifier for the pie menu (Ctrl-Tab for eg).
We do support double click events for key-strokes, I tried using A-DoubleClick, even though it works, it feels erratic.
I think users are not accustomed to double-clicking keys with a time-out (as with mouse clicks).
You can not press fast enough - nothing happens, and it means we either have to first always select all (as before), or map select all to a click/release event.
Overall I rather not support this, it just feels a bit too unpredictable.
Tested and Ctrl-W is not assigned to anything when running with factory settings.
One of the points of having a minimal keymap is not to assign actions for nearly every key - #55666
This way users have keys free for their own use, and if a new tool is added which becomes an important part of peoples workflow, it's not getting bound to obscure key combinations.
Am open to suggestions, but think in general we can leave keys free, eventually even document this in the manual so users have a set of keys they know wont conflict.
Hi Guys, Do you guys think Select Less/Select More is worthy of making it into the Default Minimal Keymap? It's a quite useful tool in modeling workflows. Especially when you have to quickly make growing selections/de-selections in dense meshes. I love how freeing the new minimal keymap is, letting us users map whichever keys we are comfortable with. :)
I was going through many un-bound keys on the keymap-list and felt Shift , (Comma) & Shift . (Period) works comfortably. They aren't bound to anything important, they're right next to each other, gives a sense of adding/subtracting given the < & > keys, easy to reach with your right hand, but can also be used with your left (with minimum hand movement) My initial thought was to use - & + keys, but those seemed too far away. Just a thought. :)
Also the change made to the 'A' key being split into two actions (select/de-select) versus the toggle action was a bit tedious to change back to. :) Nothing against the changes, as long as we are free to change back to what works for us. But man was this some work. :D
Small fraction of the list I had to change,
Wish there was a nice middle-ground for noobs like me who love the Freedom & Simplicity of the new 'Minimal' keymap. But also if/when we need to mirror a important keybind/function from the 2.7X keymap it wouldn't be daunting.
Right now, if you want the cool functionality & simplicity of the new default keymap, using the 2.7X preset is a no-go. I know this was a bit of an extreme example of having to change a lot of keybinds to get some functionality you preferred from the previous setup. Most of the time using the new default keymap, it has been as simple as Right-Click > Add Shortcut and you're done. And that is something that many users can get by. Blender Newb or Vet. :)
But the time spent on being able to change 'A' to function as a Toggle for select/de-select. And changing back the other keys to compensate. It's not something a new user or someone not that comfortable messing with the settings would do. I was so worried I'd mess something up I went keybind by keybind. 1 at a time. :( I'm sure if I knew how to code all this would have been easier, but hey. :)
Anyways, Thanks for all the hard work guys. This is all WIP and we learn new ways to do things better/different everyday. No matter what changes are made to the new default keymap, as long as assigning a new hotkey or functionality you preferred from the 2.7X setup is kept Simple & Accessible to Blender Noobs & Vets alike. We're all good. <3
I totally agree with this last statement. I really love that behaviour, it's fast and efficient. But I have to say I oftenly fail to go in/out edit mode just because I accidentally moved the cursor few pixels away (curiously, I don't really have this problem on my laptop with a touchpad). Then, the pie menu doesn't even show up but releasing the tab key does not do anything. Is it possible to make the mode switching work if the pie menu didn't show up??
Update, tab-drag has been removed in favor of Ctrl-Tab for the pie menu. See:
72e090a3cfBackspace doesn’t seem to be used for anything in the 3D View (except for edit mode for font objects). And it’s a nice, large key; easy to hit.
Removed subscriber: @MadMinstrel
Ok, I guess Ctrl-Tab will do the job. But I really think tab drag was really close from something great :)
I want to remember that in a lot of laptops and almost all apple computers F3 is a really hidden hotkey because you need to press Fn and F3 to have access to F3. Nobody uses this F1-F12 shorcuts because it's a PITA. It's at least 10% of the potential users (20% in USA). Also that few people use F3 to search, it's a common shorcut for really expert users (coders mainly). The mayority of people uses Ctrl+letter (in windows the letter depend of the language of operating system in spain is B, for example).
I want to ask if developers have though in some way to make easy to access to search (actual option in edit menu is really hide). Like, for example, to put a searchbox inside new active tools toolbar with this behaviour
Press spacebar + press letter = Active tool shortcut
Press spacebar + release space + begin to write = searchbar
It's weird some actual behaviour and shortcuts of the activetools toolbar, like after press space you need to press other hotkey (Ctrl+B) to select one active tool. I don't that newbies will learn this type of behaviours and old user will configure their own hotkeys or only the menu.
@AlbertoVelazquez, enough common shortcuts are using F-Keys (render for example).
We have AccentGrave as a easier to access key, on US/English layouts this is always available.
For non-US/English layouts we can support scan-codes, but this requires some development on each platform. It's done for Linux, macOS/win32 still need support added.
I don't think the need for development is a reason to avoid using the key, it may be only a few lines of code to change on each platform for all I know. It's just that nobody looked into it yet.
From recent experience, drawing distinctions between subtle changes in behavior tends to be confusing & annoying. It also makes switching tools significantly worse.
I think that both F3 and the accent is an absolutely hidden shorcut for new users, never in my life I would think of using both of them not for search, but simply for any hotkey, since this is not an FPS that is where that hotkey makes sense. It's hard to think that any user will use taht shortcuts to find something.
When I started with blender 6-7 years ago after 10 years using 3dsmax, I had no idea how to use the program and it had thousand of commands. One of the things that made me take risks and made the program very easy was to find myself in the first few minutes of use, by coincidence, the searchbar in the space bar. Because it allowed me to have the full potential of the program with a simple hotkey. No matter how much you like it, all the hotkeys that are being tested hide this functionality, which is essential and of the greatest success that blender had.
I know other programs don't have it easily available or don't have it directly, but blender certainly makes it better to have it in a simple shortcut. And we only have to see Android, iOS, macOS and windows10 that put that functionality on the user's face with a search bar in the middle of the user's face. I have taught blender to a lot of co-workers and without a doubt the most used thing, especially in the first few weeks, was that ability to have that help on hand. My co-workers loved the whole "how do you do this in blender?" thing and just click on space and look for a term for it. Specially when you are a expert and you know that you need to learn hundreds of things an you don't want to learn hundreds of icons in the interface and search taht icons/buttons.
I don't think it's a problem to look for a solution like the one I'm saying about the toolbar when blender currently has similar behaviors when it comes to adding nodes. And other programs like Houdini have exactly that behavior. You can polish the idea but it seems functional and uncomplicated. It is a function that is explained in itself.
Mockup
I was just messing around with the hotkey list and came across something interesting. Switching Tab key from Click to Press for Toggling into Edit Mode suddenly made it seem much 'Snappier'. Even Tab + Mouse-Drag for Mode Select Pie feels much more responsive. That micro lag/stutter that used to happen occasionally seems to be gone? Idk, maybe it's just me and some placebo. :)
I was trying this out because I've come to love the Tab: Toggle Edit Mode, Tab + Drag-Mouse: Mode Pie. (Without a doubt one of the best uses of a single key for multi-functionality.) And after I download tonight's build, I wanted to make changes to keep it the same way for myself. Was pleasantly surprised when I changed the key-press function and Tab just became a whole lot sexier! :D
This breaks using accelerator keys to access tools, which is the main purpose of having it accessible from a key.
How do you prevent the press event from being used before the drag event activates?
Looking over this task and there are some remaining things I'm unsure of.
Could we run a post process that duplicates all the key-bindings that use Ctrl?
Why? We already have 'X' key for delete. Having 3 keys for the same thing seems excessive. (Especially if you multiply out all the combinations used with modifier keys)
Hmmm. I was trying both ways out. Tab as Click or Press. Although it seemed snappier, there was a difference I couldn't really wrap my finger around. I think it's exactly what you mentioned Campbell. When I set Tab to Press instead of Click. Each time I 'Hold' the Tab key and Drag-Mouse for Pie Menu. It activated the Edit Mode Toggle as well. Seems this doesn't happen with the 'Click' method. So holding down Tab doesn't activate the Toggle Edit Mode command. And moving the mouse activates the pie menu without disturbing the current selected mode of the object. (But you already knew that. :D)
Guess that's the beauty of experimentation eh? Learn something new everyday. Thanks for clearing it up for me. Was a bit overly enthusiastic with my findings it seems. :D Still, looking forward to keeping Tab + Drag-Mouse for Mode Pie. (In my personal key config of course.) I just love it too much and it hasn't obstructed me in my workflow in anyway to justify binding a whole new key combo just for the pie. IMO, Ctrl + Tab can be used for something much more frequently used. Especially when Tab + Drag can do the Pie just fine. But that's just me. :)
Thanks man, have a good night. Also great work clearing up almost all those keymap inconsistencies. Didn't even notice until you started fixing them. Cheers.
Also +1. No to 'Backspace' as another delete. Just a waste of a key and completely pointless. Takes away the whole purpose of a 'Default Minimal Keymap'. I think 'X' for 'Workflow' and 'Delete' for 'Standard' is reasons enough.
Really? It might be only me, but every time before pressing "x" to delete something I keep pressing "Backspace" several times before getting used to "x" again. To me personally it's a mystery why on earth (I'm really exaggerating here) isn't "Ctl/Cmd+a" used to select all objects, like any other application (and every OS) does? But again it might be subjective, I just wished every new user had a luxury to find familiar key bindings like "Ctrl/Cmd+a" to select all, "Ctrl/Cmd+c" to copy, "Ctrl/Cmd+v" to paste, "Ctrl/Cmd+x" to cut, "Ctrl/Cmd+d" to duplicate/clone/link (in some combination with "Alt" and "Shift" keys), and ideally it should be possible to deselect by clicking on empty space in the viewport (complex selections can still be saved in a vertex group in between, so no need to worry about loosing it). It is no big deal to change keyboard shortcuts for experienced user, it is for a newbie who knows nothing about Blender keymap.
@orustammanapov I understand where you're coming from. Even for me, I still have to consciously remind myself to use the 'Blender' part of my brain to do certain things differently from the way my brain has been conditioned using other software for years. :) But at the same time, everything that's discussed in this task is about the 'Blender Keymap Changes'. So it will naturally follow the Blender hotkeys and how to simplify them but still keep them familiar enough for newer & older Blender users alike. They are also working on a more 'Industry Standard Hotkey Preset'. And that focuses on everything you said. Ctrl + A to Select All, Left-Click to Select, Click-Drag to Box Select, Etc.
So practically you can never have one hotkey preset that fits everyone. But don't be worried, because they are giving us the options to choose which works best for us. Even now, this Default (Minimal) Keymap is so users can have a foundational preset to build upon. Depending on their workflows & needs. Giving users the freedom to Add/Change/Remove what they like or don't like. But at the same time, like I mentioned before. There will be more Standard Presets for people who just want to Set-It, Forget-It and Get to Work with Minimal Modifications. :)
For example. If you find yourself out of habit pressing 'Backspace' everytime you want to delete something. By all means. You have the freedom to replace Delete/X with Backspace. That's the whole point of this Default 'Minimal' Keymap. They give us a good starting off point. We can customize it according to our Habits/Needs/Workflows. And that's always a good thing. --- I myself have changed many keys in the past few days and I'm still experimenting with other ideas. I could never do that with the old Blender Preset. It was too convoluted with keys that I didn't use or need. I didn't even know where to start, which ones to replace without affecting something else.
What's being discussed/debated here is about what keys to ship as 'Default' with this new 'Minimal' preset. But by no means does it mean you, the end-user is going to be blocked from customizing it to your needs. On the contrary, the whole purpose of this new preset is to 'Encourage' users to create their 'Own' Blender Keymap. --- With this Minimal Preset. I get to choose what works best for me. :)
Also I'm pretty sure they will make it easier to modify hotkeys with a more intuitive Hotkey Editor in the future. The current one does the job well, it's pretty accurate. But for a beginner it can be quite intimidating as you said.
pressing Cntrl/Cmd + a is really less effective than simply "A" some people dont have the flexibility to stretch the hands on some keys fast or accureately, and for most frequently used commands like "select all" its better to not put muscular pressure, at least your finger joints will last longer...
And I will be honest, there is easy way to learn all the key shortcuts of blender really easy.
SLAP your hands on
"A" for toggle select is one of the best things Blender has, why splitting the action and adding "ALT+A" Also will there be another shortcut for creating a custom manipulator orientation? previously "CTRL+ALT+Spacebar" another of Blender strengths.
Don't know if it has already been mentioned here, but in the Python console,
ctrl+spacebarfor maximizing the editor is in conflict with autocompletion.Just a note, but this idea that
⌘should be used on the Mac where other platforms useCTRLshould have been abandoned long ago. It dates from about 1984-87, before Mac keyboards hadCTRLkeys. (In other words, from before the living memory of most of those reading this.) It makes more sense to treat⌘as equivalent to theSUPER/WINDOWSkey.Beware of
CTRL-PAGE_UPandCTRL-PAGE_DOWN— these would conflict with the keystrokes for adjusting the auto IK chain length. Interestingly, this seems to be hardcoded — I can’t find it in a keymap anywhere.In macOS/OSX
⌘is used likeCTRL,SUPER/WINDOWSkey doesn't have a lot of uses in windows except for OS shorcuts. But⌘is a basic key for anything in macOS and normally is the key that you use for all shorcuts , for example copy&paste is⌘+Cand⌘+V. Because in macOS you haveCTRLbut no one uses it in the believe that is hard to use instead the⌘, something that I think that it's true.Thanks for pointing this out, it applies to the text editor too, checked and this prevents the console/text-editor from going fullscreen via a shortcut, thats not great, but not necessarily a blocker IMHO. We had similar conflicts in the past for eg with Ctrl-Left/Right being used to switch screens, getting used by the text editor for cursor navigation (no longer a problem with the new keymap).
Looking into this further, we can use Shift-Space for auto-complete, since animation isn't activated from console/text editor, although this would become annoying when typing capital text that contains spaces.
Why not have a preference to swap [OSKey / Ctrl] ? It seems this is what Mac users expect, some extra work would need to go into making key shortcuts display properly.
I couldn't find this anywhere, do you have an example of how to use this binding?
Control of the Auto IK chain length is documented here. You might remember this patch to the relevant docs.
I think that the best would be
tab, like any other console, but I don't know if it is conflicting with something else, but yes as you said it is not really blocking :)Good morning everyone. :) Small issue I'm facing. I'm trying to maintain a custom hotkey preset separate from the new default. So whenever the default is being changed/updated (which is the whole point of this task: #55162), I wouldn't have to keep changing back certain/most keys I've setup for my personal workflow. Here's what I noted.
Whenever 'Certain' hotkeys are changed in the Default preset, it's also changed in my Custom preset. (Which is Expected) eg: Recent changes to A / Alt + A for Select/De-Select, Ctrl + Tab for Mode Pie Menu, Etc.
My understanding is, these changes are 'Global' and affect the core keymap code as a whole? Hence why I'm keeping track of this task for changes and modifying my custom preset accordingly.
eg: I prefer 'A' as a toggle for Select/De-Select, and Tab + Drag-Mouse for Mode Pie Menu. So I changed them in my custom preset. Simple. :)
Issue is, when I switched back to the default preset. The above changes have been reflected on that as well. Didn't expect changes made to a custom preset to affect the default in anyway.
Although the opposite seems to be true. Changes made to default affects Some hotkeys on all other presets. Including custom ones. (Again, I expect it with code changes.)
I say 'Some' because I noticed. None of the changes made in yesterday's commits for the 'Keymap Inconsistencies' has made it into my custom profile? But are changed in the default.
The whole point of maintaining a custom preset is so, 1) Not to disturb the default profile in anyway with custom changes. 2) Not having to redo all your personal keybinds every time Blender defaults are changed/updated. (keeping both separate, one shouldn't affect the other. --- Or at least, not so Inconsistently.)
The only way I've found to reset the changes that have mirrored onto the default preset, due to me updating my custom setup is to, Export Custom Preset > Load Factory Defaults > Import Custom Preset.
Would be nice if the Default Input/Keymap Preset is saved 'Separately' from the 'userpref' file. So you can 'Reset Only' the Input Settings and nothing else.
eg: Pablo has been making tweaks to the Default Theme the past couple of days. And it's been quite simple each time I download a new compile of Blender to just hit 'Reset to Default Theme' and have it update to the new changes. :)
Affinity Photo has this section of the User Preferences where you can reset 'Individual' parts of the program. Just an example.
As for the other issue. Some defaults force update the default & custom presets. Others don't. Like the keymap inconsistencies changed yesterday. eg: Image Editor Unwrap: 'U' in default. But still 'E' in custom preset, etc.
Only way I know around this is to 1) Make changes 1-by-1 to my custom preset, depending on what has changed in the default. (this task) 2) Load factory defaults > Modify the keymap (again) with my personal keys, so that I'll get 'best of both worlds', the newly updated defaults/changes and also have my custom keys. And export it for safe keeping. --- But since the new defaults are quite in 'Flux', this is better done when everything is finalized and I'll only have to change my custom keybinds just one time before saving it out. :)
Wish there was a simpler way where, Whenever the 'Defaults' are changed/updated. It will update all the presets. As it does now. But completely. Not just change some and ignore others. And only change/update the keys where the user has 'not' modified. eg: If I have custom set 'Extrude' to 'E'. Then even if the default is changed/updated to 'Ctrl + E' it shouldn't change it.
And if the user wants to update 'Everything' to the new defaults, this is where a Reset Keybinds button would come in handy. :) Would be even more awesome if we could have two buttons. Reset Keybinds (This resets 'all' keybinds to default.) Reset Unedited (This would reset everything 'except' keybinds which have been modified by the user.)
Just thinking out loud. Hope this made sense. If we could make Editing/Updating/Resetting Keybindings easier for new & veteran users alike. Where you can modify keybinds to suit your needs, but not lose the new changes made to the default without disturbing the default preset or what you have in your custom preset. Or at least if merging the two wouldn't be as destructive or difficult. That would be Awesome! :)
If we only make tab auto-complete for the console we would need a different key for the text editor since this is used for indentation.
Also the PyConsole supports indentation, although in this case its common to detect initial indentation or typing after existing text.
@JonDoe286, Making custom keymaps is important, especially if we make our keymap more minimal.
However this is a big topic, you raise valid points, but this is out-of-scope for changing the keymap.
@ideasman42 Yeah. It's all good man. :) This is in no way one of those "Fix This Now!!!" requests. I can imagine how much work it will take to have a Keymap system like that, with difference scanning, selective resetting and selective updating, etc. Since we are discussing about keymap changes and also this seemed the most direct place to share this idea with you guys. I hope it's something we can work towards in the future. :)
For anyone who wants the tl;dr from my top post.
Added convenience feature for experienced users: Alt-MMB(drag) for view axis switching:
1bf5cc57bdIts for experienced users, of course existing methods for changing view axis remains.
Added subscriber: @JamesPrakashJC
Hi, I'm not able to center the 3d cursor with SHIFT+C in 2.8. Is the the shortcut changed or what? or is it a bug? It's really annoying though cause I can't add in new meshes in the center of the scene. Can anyone help me, please?
@JamesPrakashJC Hi James, In the new Blender 2.8 keymap, Shift + C > Center Cursor and View All function is not-bound by default. You can find it here. (View > Align View > Center Cursor and View All) --- Feel free to Right-Click > Add Shortcut > Shift + C --- You can also use Shift + S > Cursor to Center.
As for zeroing out the values for 3D Cursor (XYZ) in 'Sidebar' (N) Panel. Not updating in the viewport. It doesn't work properly at the moment. Sure it will get fixed in time. Hope this helped. :)
Added subscriber: @thedaemon-3
Who thought A: Select All and Alt-A: Select None was a good idea? It used to just be A, now you've made it 2 hotkeys? This is not how you help anyone.
Also, where is ALT+Mouse scroll to change Frame #s? Did I miss it being moved to something else?
@thedaemon-3 well the idea is that now you dont have to go through double tapping A, wich meant selecting everything before deselecting, which in heavy scenes was really a big fat mess.
Separate keystrokes for select-all versus select-none is a good idea.
Is there any reason why
QUOTEis not used for anything? I posted a.blendfile which bindsQUOTEto select-all andSHIFT-QUOTEto select-none in every editor, just to see how it worked in practice.Artists in the Blender Studio requested separate keys for select/de-select, since they occasionally had selection outside the view and select/de-select cycle isn't as predictable.
(Caused some accidents)
An argument can be made for this being better for heavy scenes too, although on it's own I don't find this argument so convincing.
Btw, as far as I see - nothing prevents us from setting A to be "toggle all / nothing", and Alt-A to "select nothing".
while a deselect hotkey can be useful, removing the utility of A doing both is a mistake for users who are not going to know that A is capable of doing both and are not going to look for that option. In addition to forcing all former users to retouch the hotkey (this and a hundred other hotkeys) to work as traditional Blender.
But after eight years of using blender I don't see that there are any "accidents" with this key that justify deactivating this functionality.
@JonDoe286 Oh thanks. It sure helps. :)
In keeping with the "workflow" mentality, would it be possible to get a context-based deletion behavior by default when pressing "x"? Like the Smart Delete addon.
In Blender, it's always a two step process of having to go through the delete menu then selecting the desired delete option. If it was made smarter, it'll just help speed things up physically, but also mentally, so the user doesn't always have to pause a split second to think about which deletion option to use every time.
For the rarer cases when needed, the Delete menu should be accessible via a hotkey.
Also, there should be an option to disable confirmation for stuff like deleting objects. There seems to have task for this very reason (https://developer.blender.org/T37422), but unsure what happened.
@ideasman42 Hey Campbell. Just checked out the list of 2.8 keymap changes. Looks pretty good. :) Think it would be good to mention both instances of Playback Animation? --- Playback Animation (Fwd): Shift + Spacebar / Playback Animation (Bwd): Shift + Ctrl + Spacebar
@JonDoe286, added - Shift + Ctrl + Spacebar
Added subscriber: @bent
It would be neat if there was a "cycle" option for the "type" selector in the key binding menu. I'd like to press "z" and it goes to the next mode of shading
is there a way to set up search as double space?
F3 doesn't work from the toolbar menu and it's just personally irksome to have to take my hand out of typing position when i'm about to have to type.
setting it as double click spacebar seems to be ruined by the toolbar popup on space.
I dont see how Select-all can be unpredictable, for me it works fine.
I tried the last blender, please make a A - toggle selection again its freakin anoying how it locks blender.
Continuously pressing A is way more plesant than having to think "Wait this is not Alt, I pressed the wrong button again"
Find-operator should be on
/. This is the key used in Gimp for its search function.Fixed
b2d8f83444Agree, would be nice to use this for searching (edit, this is used for search in other applications too - Firefox, Vim, even Facebook & YouTube use this).
OTOH, why would the default search function search for tools? - Wouldn't it be useful to add the ability to search for content, based on the editor type based on names, or file paths, or asset tags? (objects, images, layers, sequence strips .. etc)
why wouldn't it search for tools? sometimes you know the name of what you're wanting but not the hotkey, not everything has a hotkey, sometimes tools are added with addons (like looptools for example).
though i agree it might be useful to add the ability to search for other things.
This comment was removed by @AlbertoVelazquez
This comment was removed by @jeacom
This comment was removed by @ldo
This comment was removed by @AlbertoVelazquez
While none of the comments removed just now were inappropriate, the general direction was moving off topic.
Turning into forum style back and fourth only loosely related to this design task.
For more general discussions relating to Blender's keymaps, post here:
This comment was removed by @jeacom
This comment was removed by @jeacom
This comment was removed by @jeacom
@jeacom, please move discussion to the links posted above.
If you have a statement which you feel helps this design task progress, make it. But try avoid noisy forum comments/disagreements here.
Added subscriber: @Alex-9
Numpad + /is used in 2.79 asLocal view./could be used for keyboards without numpad andnumpad emulation modeas there is no key for this action when numpad is missing. But as~is used in 2.8 forview pie menu, then maybe some~related shortcut is needed like e.g.Alt + ~@https://developer.blender.org/p/looch/ Heavy scene issues make sense about the alt+a hotkey. Selecting everything can be a killer. I can always customize my hotkeys :)
Added subscriber: @nokipaike
for compact keyboards without a numeric keypad, convenient shortcuts are required for the very essential "frame select" command (numpad .)
and also for the "local view" command (numpad /)
There's no option to select and toggle v/s/r recursively in outliner. Ctrl key is now used to isolate selection by ctrl+clicking on visibility icon (but seems like without possibility to reverse action as alt+H shows all objects regardless of state). Maybe alt or shift +click on object icon and v/s/r icons can be used for this now (as previously ctrl), as this is feature is essential for working with parented objects.
Added subscriber: @ancientbuho
Most tools in edit mode leave the current selection selected so that you can continue doing other actions to the selection. If you are done and want to see how the action looks like without distracting selection highlights, you have to deselect. It is always a thing you do, you deselect after doing anything, to see how it looks. Previously it was super easy with "a". Now it is cumbersome with "ctrl-a". "A" now is the super rarely used "Select All".
I'd rather switch these two, "a" deselects all, "ctrl-a" selects all. That, or keep "a" for selection, and use another key without modifiers for deselection.
Or, you just go to the Tool Shelf, expand the Display panel, and uncheck and recheck “Outline Selected”. No need to actuallly change the selection at all. Simples!
Thank you but sorry, that doesn't help.
First, it's way more work than even alt+a, considering that you'll have to re-enable it to be able to start new selections and that it's quite buried between other options.
Second, it doesn't work with selected vertices in edit mode.
Third, being able to quickly deselect is still quite important - removing the highlight is just one reason. This is why I deselect:
Really, I didn't know how much the "A" key was used after I tried 2.8. With the exception of right-clicking to select, every selection tool (lasso, box, circle select) adds the new selection to the previous selection without modifiers. That's awesome, and allows for quicker workflows. This behavior relied on a quick deselection shortcut for it to not be annoying though.
Other graphics software (I am thinking of 2d vector programs) clear selection via other means, such as deselecting when clicking outside of the selected items. But Blender doesn't unselect when clicking outside of the selection because that's used for "grab / move" the selection. So, "A" was filling that void.
Added subscriber: @a.monti
Hi! I was wondering if changing V / Alt-V for controlling the backdrop zoom in the compositor had been considered yet, I've always found that confusing and to me it doesn't really make sense.
Maybe that could be assigned to Alt-Mouse wheel, it would be coherent with Alt-MMB currently used to move.
Alt + A for deselection is freakin anoying for sure.
Could I make a suggestion?
Pie meus are the best workflow assist that any user has ever seem.
Lets apply the same solution that was taken on Tab for edit mode:
Just make
Ainvoke a Pie menu with several selection options if it was dragged, in special: Deselect and Invert.If there's no drag event it behaves like before.
Just to give my opinion without trying to generalize what I personally like, with what others may like or suits them.
I do not feel comfortable with Pie Menus, I do not use it.
About Alt+A, I have found certain advantages to this new behavior and in fact I have started to like it. For example you do not need to be looking at the screen and analyzing the scene to be completely sure that you have selected or deselected all.
Added subscriber: @vikrant
I am not able to find the shortcut to set origin in 2.8, earlier it was ctrl+shift+alt+c, anyone knows what is the shortcut in blender 2.8?
@vikrant Hi Vikrant, It's currently not bound to any shortcuts for the default 2.8 (minimal) keymap. You'll have to manually create/bind it in the input settings.
User Preferences > Input > Expand 3D View section. --- Under 3D View, look for Object Non-modal section. Then click on Add New button. --- Then paste this operator line into the empty box; object.origin_set -- Set keybind to Shift Ctrl Alt C, as shown in the image and you can have the Set Origin functionality back as before. :) Hope this helped. Cheers.
Added subscriber: @AditiaA.Pratama
Added subscriber: @pipmaker
About: continuous grab + Select LEFT + emulate 3-button mouse
Hello all - since I'm new to this phorum:
my name is Martin, coming from 3DS / XSI / Houdini (since 1999, non-professional CG)
I've been looking at blender for a while now: you are doing an AMAZING job!
Context:
While I like Houdini a lot for all its technical aspects and can do's,
node-based construction can be so uninspiring to the "creative side" (Hello Mari ..)
All I was hoping for was a different UI, more like modo, and as of yesterday:
(As a developer I might even dive into things and help out as time allows)
Now, reason for this comment as call for help:
I'm mainly using ol' trackman but without RMB clicks due to CTS,
and with the adjusted settings (see below) most things work just fine (less the issues already on your radar), but one remains:
After selecting anything by mouse action it keeps grabbing things. I suppose this is "continous grab"?
a) How can I disable grab on mouse action / select after releasing the button?
b) It appears, if object has been moved, click deselects at first, but in some instances (e.g. tab > edit mode) one click
(intended to select vertices) keeps grabbing the points right away, and points are moved without warning.
It's a complex issues altogether, I understand.
For now it would help to be able to disable the continuous grab on mouse action/select, but keeping it a G
Any help or hint would be much appreciated,
Thanks and keep up the excellent work,
I'll stay in touch :)
Cheers,
Martin.
Added subscriber: @1D_Inc
Current Blender Keymap Inconsistencies:
V - Merge vertices
Alt+V - Rip verices
have horrible defaults
Tilde for searching is bad soulution, because, obviously, ~1 ~2 ~3 is for switching modes (verts, edges, faces), while 1 2 3 4 5 is for setting collections visibiliy or whatever there will be there instead of layers to provide ability to compare modeled objects to refrence volumes. Didn't you forgot, that Blender 2.79 can be used for complex modeling?
So stop killing that feature already!
By the way, what is the problem with spacebar?))
Who will dare to say "it is not consistant" to professional modeller and developer?
Unless you explain the reason or offer an alternative this is not helpful very much.
I personally have :
Ctrl+V as vertices menu
Shift+V as remove doubles
V as rip vertices
Alt+V as rip faces
Well, because of relevance.
Button is action, alt+button is inverse action - common logic of most functions in b3d
Obviously, M is too far away from WASD to be convenient at any circumstance, you have to move your hand to press it, but this function is used very often.
So V for merging Vertices is direct action, alt+V - getting opposite is easier to use and remember.
Shift+F as remove doubles (can be described as Fuse / Frit) while Shift+C (Camera flyover) that stands for flyover camera navigation are looking much more pleasant.
There are also some less convenient but yet a lot of useful for edit mode
Alt+D - cursor to selected (while it isn't used at all in edit mode)
Shift+X - Assign current material to selection (fast and allows to painting materials fith latest selected polygon at fullscreen)
Q - select linked all (it seem be almost impossible already, but this is much more convenient than L for this incredibly popular action in modeling)
Because are free
Alt+W - mark edge seam
Alt+Shift+W - unmark edge seam
Alt+Shift+E - mark sharp
Ctrl+Alt+Shift+E - unmark sharp
And super secret, but also the most clever and convenient - RMB for move view (including knife tool navigation re setup).
That brings incredible freedom of full onlymouse navigation, removing need to use both hands...
every single time
...you need to pan your view.
This one is pro setup of enlightenment level I would like to share with you.
Actually, Alt+D is used in edit mode, it's the "extend vertices" operator. Also Q in 2.8 calls the quick favorites.
Yes, that's why I called Q almost impossible.
Yes, Alt+D was binded before extend vertices were invented, so extend was moved to Alt+Shift+D.
However, this one is not much important and depends of modeling (CAD/organic) style.
What about Shift+N - flip normals, ctrl+shift+N - recalculate?
(I use ctrl+Q and strl+shift+Q because of relevancy)
Yes.
But there is the trick - layers were used for quick visual control.
Users can control 20 with keys, and that is enough for quicksorting and managing scene.
My proposal was to hold all unsorted collections as bottomless layer 0, any new collection that was created goes there, so user can place desired collection to one of 19 controllable layers (numrow 1-9) in order to provide it's visual control and quick recall on demand.
If there will be no collections to sort - layer 0 will became empty, that will mean, that scene is fully under visual control.
This concept allows to use 1-9 nums and also prevents visual layer's gui.
We not only have infinite possibilities of collections, but also sub collections. In my opinion, the best way to manage them quickly is with a hotkey + numpad. It would also be ideal if developers could achieve a method to visualize better position number of collections in the outliner stack.
https://devtalk.blender.org/t/blender-2-8-user-interface-design/505/594
Given that collections have names, isn’t the most logical thing to do is allow typing the initial part of the name, and offer some kind of autocomplete?
What for?
To find some? Maybe.
To isolate some of them and temporaly switch off for comparing something? Really not.
Placing something in outliner stack means permanent outliner scrolling.
Not sure what you mean:
Vis Rip not Merge.Added subscriber: @carlossifuentes
Please consider disabling this option is always annoying for beginners
Which option?
With the new menus flip-normals isn't available in the context menu or the face menu.
We could have a key binding to access this, will check with @WilliamReynish & @venomgfx since I think this is a commonly used operation which could be in a popup or have its own key.
Removed subscriber: @jenkm
We could add Flip Normals to the contextual menu
Yes. I mean
that RIP function
was set to V as mistake
and there should be Merge instead of it
to make it clean and match "action" - "alt-antiaction" pattern for V and alt+V
I've made explanation further my post about it
It will be nice solution, because it is one of two basic normals operations, it will definitely deserve to be placed together with recalculate normals in gui and share close enough shortcuts.
disable "translate move tweak "
it always happens that the selected object is hooked to the cursor
for "left click" key map
That's because what you really do is "Grab" the object. That is why it was always called "Grab" before 2.8, and this is very useful. While you keep "grabbing" the object, you can perform actions, such as the Middle Mouse Button of the Mouse or the pen of a graphics tablet, or from the keyboard.
I was a beginner and I never had a problem with it. Maybe only for those who are used to other programs.
I confirm, translate tweak is useful, especially in edit mode.
It is better to new users to handle this feature, than turn it off.
In Blender currently we have to click "x" and choose from a menu to delete in edit mode. This could be simplified easily I think. Just pressing "x" after selecting an edge/s or vertex/vertices would just delete it away with any faces linked with it If it's a face you selected than it would delete that faces or faces. Pressing "SHIFT + x" would dissolve edges, vertices, or faces. And "CTRL + x" would bring up the traditional Blender "delete menu". Comment any suggestions you might have to perfect this idea. And if any developer decides to implement this in Blender please let me know in the comment section, cause otherwise I'll be on tender hooks xD. Thanks.
@JamesPrakashJC, Ctrl-X is currently used for dissolve for mesh, curve, armatures and nodes.
@ideasman42 , I just checked, yea you're right. then shift + x could be for the delete menu. But personally I found that shift + x is more kinda accessible.
Added subscriber: @TheRedWaxPolice
Hi.
Why the ALT key is not used for subtract in sculpt mode, instead of CTRL? It would be more in line with how generally the hotkeys work in Blender (A/ALT+A, H/ALT+H etc), and also would be more compatible with other sculpting apps like ZBrush etc..
Shift-X is delete globally (in object mode - removes from all collections).
I have another proposal about Deleting (X), Linking (Ctrl+L), Merging (V for me), Specs (W), Edges/Faces/Verts (Crtl+E, Ctrl+F, Ctrl+V) and other similar menus behaviour.
While working you often need the same operation in a row, for example
X - Dissolve Edges, X - Dissolve Edges, X - Dissolve Edges while clening mesh, or
Ctrl+L - Materials, Ctrl+L - Materials, Ctrl+L - Materials for setting up materials, or
Ctrl+E - Edge Bevel Weight, Ctrl+E - Edge Bevel Weight, Ctrl+E - Edge Bevel Weight for marking edges
My proposal is to set last selected action on double press of same shortcut, that calls menu
For example,
pressing XX will dissolve edge if it was last deleting operation,
pressing VV will merge at center, if it was last merging operation,
Ctrl+E - E (quick pressing E second time while still holding Ctrl)- will set Edge Bevel Weight if it was last from Edges menu, and so one.
Double press on new scene will call first menu element, if there were no other option called from menu before
@1D_Inc your proposal conflicts with menu accelerator keys which use letters already,
IMHO your suggesting changes which are outside the scope of this task.
Maybe yes.
Maybe there will no longer be such an opportunity for this.
Menu accelerator keys cannot match with menu item keys (otherwise, you need to block menu manually),
and if to press any calling menu keys twice there is just no any reaction by default - so all of them are free.
Оn the other hand, there is a lot of double pressing realizations already, like GG, RR, GXX, SYY, II etc, that, basically, calling single suboptions like local axis restriction.
So, everything is pretty much ready for such concept implementation.
That would be great workflow speedup.
Added subscriber: @ThinkingPolygons
Good point.
Obviously, because Alt is not better than Ctrl.
It is harder to find by touch and some keyboards have only right Alt.
Also compartibility with Zbrus? Program with interface and navigation which loose to sculptris? A 2.5d painting program, where all sculpt is just creating brush for painting?
No, we don't need compartibility with such program.
We'll let them chance to take Ctrl as better option from Blender.
@1D_Inc If you think about consistency inside of blender, you'll realize that using ctrl for subtract doesn't make sense there.
There is noting can be about consistency but about relevance and accessibility.
Relevant functions should be accessible easier, not "like in Zbrush" or "Substance Painter."
If you are setting default button to a key, that even don't exist or is moved on some keyboard types, obviously, you are making mistake.
Also.
There is no consistency about Alt in sculpting, because it is not shortcut, as far as it requires pressing.
So both Alt and Ctrl have the same consistency.
What you are saying makes no sense to me, but no worries. If people is ok with it, then it's fine. I changed my hotkey to alt already. Cheers. ✌
Note that I can't keep track of this discussion - enough of these comments are too vague or assume we know exact behavior of other software.
Please try make your comments self contained so we can understand them.
Ctrl is not really Subtract in sculpt mode. Ctrl does the opposite of the selected brush mode you have. If you are in brush Subtract mode, then Ctrl add.
What I think (not sure) we are missing is the possibility of assigning a shortcut to an Add/Subtract toggler to change the mode without having to permanently keep pressing a key, and probably if it were possible I would assign Alt to that toggler (or Alt+something).
Of course that's what I mean. I'm saying subtract just for easy understanding, since most common brushes usually come in add mode by default. And yes, as you probably know, that's usually the purpose of the ALT key, to do the opposite of a action. That's why I also think the alt key would make more sense for that. And as a bonus it would make the jump between blender and zbrush more painless. Now I'm trying to figure out how to map the mask brush to the ctrl but only while I'm pressing it. Don't know if that's possible tho. ✌
**@Campbell Barton ** Sorry. We are just discussing the use of the ALT key instead of the CTRL in sculpt mode, to do the Invert action of the brushes (add/subtract). Currently it's the ctrl key, but alt seems more appropriate imo.
Well, if you changed it to yourself, it seems, your keyboard even have an Alt button, so problem has gone.
Ctrl don't need to be changed because that change already not making sense to you)
Added subscriber: @Znio.G
how you guys going to handle lasso masking? i think right now it's shift+ctrl which only adds i don't think works well..probably should be exposed as a separate mode that only activates when ctrl is on, like other sculpting apps.... so the hotkeys is ctrl adds and ctrl+alt subs whenever the mask mode is active..
There is problem of "shaking hands" - you can accidently drag something, for example, trying to grope object that you need through a bunch of other objects in wireframe mode, by clicking LMB too fast and moving mouse a bit with every single click.
That's happening like this
LMB click - drag - LMB click
and instead of "select something wrong, aim other object, try to select it"
you "started moving something already selected, then move it a bit and confirm it's new location"
Then you are pressing Ctrl+Z, and in a large scene it tooks one or two eternities to undo that little shift.
Unfortunately, this transform.translate function is useful when it is used as it was designed - for quicks moving objects, or, for example, retopology.
I'm pretty trained modeller, so I handle it with pressing LMB-RMB for every selection.
Here is GIF
So, kind a solution can be delay timer in transform.translate , that blocks accidental LMB releasing, making this action look like
LMB click + drag (starts timer ~0.3 sec) - LMB clicks doesnot work untill expired timer allows to confirm with LMB click.
That's explanation of this trouble.
That's what I'm talking about. Ctrl should be only for mask operations, and alt for the invert action.
About accessibility and relevance.
Sculpting gets higher priority in relevance, so it uses easy acces buttons:
LMB - nice for direct sculpting
Ctrl+LMB - nice for substractive sculpting (as it is used more often it uses key with easier access.)
Shift+LMB - nice for smoothing
Lasso priority is lower, so it uses more complex and hard to reach buttons
Ctrl+Shift is nice for lasso.
Alt or Alt+Shift should be inverted lasso selection in sculpting - because ALT is still not present on some keyboards and it can be replaced with Ctrl+Shift "Value inverted" setup.
i don't think which keys accessibility matters more than the functionality. the user can always switch them for his/her own preferred workflow as long as it's provided and not hard-coded. their functionality is the big concern here, how the masking works in term with other brushes...etc, personally i use masking more often and i prefer adding/subtracting than smoothing in general but i think others opinion matter.
Added subscriber: @ZsoltStefan
The command "Center View to Mouse” is missing from the new keymap (used to be Alt-F). I also posted this in the blenderartists thread .
The problem with this is, that this command can only be used as a hotkey. It has an immediate action, and it uses the exact location of the mouse cursor. It wouldn't work from a menu. Could you please add it back? The command is "view3d.view_center_pick".
Even better if it has a one-key shortcut, it is a very quick and precise way to navigate the 3D view, about on the same level as rotating, panning and zooming.
...
Indeed, I use F button in object mode for "view3d.view_center_pick" and doublescroll as zoom selected in edit mode.
A very useful function, definitely needs attention.
Added subscriber: @venin
Added subscriber: @DanielGrauer
Added subscriber: @MD.FahadHassan
Hi, is there any particular reason to give spacebar + 4as move tool shortcut? I have changed it to spacebar+Gwithout any harm since G grab is still the shortcut. Isn’t it much more convenient? Searching for 4 takes time!
@MD.FahadHassan When spacebar is used to activate tools: spacebar-g is grab tool by default.
Hi @ideasman42 Thanks for your response. I am not sure if I have described it correctly. I was talking about this move tool. As G is still just like 2.7 grab, I think spacebar+G will make sense to activate move tool instead of spacebar+4 .
Thanks. Blender 2.8. hash:
a49fdbcc67@MD.FahadHassan not sure why you see 'spacebar-4', reset factory settings, set tools as primary action for spacebar in the preferences and it should be
spacebar+G.@ideasman42 Already did it. I will confirm it with tomorrow build. Thanks.
@ideasman42 It's showing 4 here too.
Confirmed, this only happens when using LMB select.
This is a bug, G to move does not work at all in LMB mode
Fixed
220ab6290eThanks @ideasman42 :)
Added subscriber: @Ferodun
There is some improvemet concept for collections shortcuts.
Currently, 1234 buttons shows a collection, but sending objects requires name in menu (M - "Collection 1" - "Collection 3" for example)
That would be nice if moving to collection will also support their number.
For example, "5" button shows collection called "Lighting Collection", so pressing "M5" will send selected objects to it.
@1D_Inc thanks, added as a paper-cut #61492
Hi. Will the "Set Origin" menu return in Blender 2.8?
It used to be
Shift + Ctrl + Alt + Cin 2.7x, and now it's gone in 2.8.@TheRedWaxPolice. addressed this here: #55194#626933
Changed status from 'Open' to: 'Archived'
Archiving this task because most of the design has changed from the original and these tasks are better to follow the current state of the keymsp: