Blender 2.8 Blender Keymap changes #55162

Closed
opened 2018-05-23 14:19:52 +02:00 by William Reynish · 358 comments

(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:

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

Changes

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

Switch Modes: 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.

Screen Shot 2018-05-24 at 10.39.10.png

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:

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

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

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

Notes:

  • Tools without immediate access auto-assign a key.
  • Holding Space, moving the cursor and releasing can be used as a quick way to switch tools (like a pie menu).
  • Arrow keys can also be used to navigate to a different tool - starting from the active tool.

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

Viewpoint Switching: Numpad numbers & Tilde (~) Pie Menu
This makes it more consistent, so that the number keys work in a consistent way, both for laptops and desktops.

Switch Workspaces: Ctrl+Tab (next) & Ctrl+Shift+Tab (previous)
With Blender 2.8, we are introducing workspaces. We want to make switching between them easy. We want to make it work like switching browser tabs.

Pivot Point: Period (.) to cycle though them. Hold period (.) to display pie menu with all pivot options
This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the period key to cycle through pivot options, or they can hold down period to display a pie menu for quick switching.

Orientation: Comma (,) to cycle though them. Hold comma (,) to display pie menu with all orientation options
This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the comma key to cycle through orientation options, or they can hold down comma to display a pie menu for quick switching.

Here’s a more concise overview of the changes:

Key Change Status
Edit Mode Tab done
Mode Tab+drag done
Sub-modes( Vert/Edge/Face) 1, 2, 3 done
Search TIlde or F3 done
Active Tool Switching Space done
Workspaces Switching Ctrl+Tab & Ctrl+Shift+Tab done
Pivot Switch Period (.)
Orientation Switch Comma (,)
Viewpoint Switching Numpad Numbers & Tilde key (~) Pie menu done
Collections Switching Dash (-)
Favourites Menu Q done
Context Sensitive Menu W done

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

Current Inconsistency Similar To Fix Status
Image Editor Unwrap: E 3D View Unwrap (U) U done
Mesh Edit Mode Vertex Ungroup: None Object Mode Ungroup (Ctrl-Alt-G) Ctrl-Alt-G done
Select Mirror: None Pose Mode Select Mirror (Ctrl-Shift-M) Ctrl-Shift-M done
Lattice Edit Proportional Edit Connected: None Proportional Edit Connected (Alt-O) Alt-O development needed
Flip Ctrl-F Switch Direction (Armature) & Flip Quats (Pose) (Alt-F) Alt-F done
Pose Mode Flip Activate/Selected Bone: Shift-Ctrl-F Select Mirror (Shift-Ctrl-M) Shift-Ctrl-M done
Dopesheet Sample Keyframes: Shift-O Conflicts with Proportional Edit Profile (Shift-O) Shift-Alt-O done
Mirror: Shift-M Mirror: (Ctrl-M) Ctrl-M done
Graph Editor Sample Keyframes: Shift-O Conflicts with Proportional Edit Profile (Shift-O) Shift-Alt-O done
Mirror: Shift-M Mirror: (Ctrl-M) Ctrl-M done
Node Editor Ungroup: Alt-G Ungroup(Ctrl-Alt-G) Ctrl-Alt-G done
Animation Channels Ungroup: Alt-G Ungroup(Ctrl-Alt-G) Ctrl-Alt-G done
NLA Add Meta-Strip: Shift-G Add Meta Strip (Sequencer): (Ctrl-G) Ctrl-G done
Remove Meta Strips: Alt-G Remove Meta Strip (Sequencer): (Ctrl-Alt-G) Ctrl-G done
Particle Mode Tools: None Paint Tools (Various) Various
Outliner Add Driver: D Add Driver (Ctrl-D) Ctrl-D done
Remove Driver: Alt-D Add Driver (Ctrl-Alt-D) Ctrl-Alt-D done
Duplicate Object: None Duplicate Object (Shift-D) Shift-D development needed
Duplicate Object Linked: None Duplicate Object Linked (Alt-D) Alt-D development needed
Clip Editor Center Current Frame Numpad Period (.) Center Current Frame (Numpad 0) Numpad 0 done
Sequencer UnMeta Strip Alt-G Ungroup (Ctrl-Alt-G) Ctrl-Alt-G done

Mac Keymap

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

  • We want to globally support the Cmd key in addition to Ctrl
  • We want to support Backspace for Delete
(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: * Mode selection is very inconsistent * Switching to some modes is not possible from certain modes * The hotkeys to change modes changes depending on the active mode * Tab to toggle Edit Mode is fundamentally in conflict with the fact that we have more than two modes * The laptop-oriented option ‘Emulate Numpad’ is not good * It makes switching between desktops and laptops a pain when they are not consistent * The row of number keys don’t spatially communicate the view directions, unlike the numpad numbers * It’s a pain for users to have to manually switch this setting depending on the keyboard they are using. * Space bar to switch active tools conflicts with the Operator Search feature * It’s inconsistent if it’s double tap space some places, and single tap space in others * It makes Operator search slower to access if you have to press space twice. * Number keys to switch layers no longer map well to 1-9 number row keys * We can now have an arbitrary number of collections, not just 20 * Users can also have less than 20 collections, rendering the number keys useless in that case * Collections can be nested, so mapping to 1-9 will produce unexpected behaviour * We have many shortcuts for specific enum settings (eg period for 3D Cursor Pivot) * This makes it hard to learn all the shortcuts, because users have to remember many hotkeys for one feature * This makes our keymap very bloated, because one feature (eg pivot point) uses multiple keyboard keys * This means many useful features (eg orientation) cannot be quickly accessible from the keyboard ## Changes With the above problems in mind, here’s how we are thinking of changing the default keymap in Blender 2.8: **Switch Modes: *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. ![Screen Shot 2018-05-24 at 10.39.10.png](https://archive.blender.org/developer/F3446635/Screen_Shot_2018-05-24_at_10.39.10.png) **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: - `G` grabs - `Space-G` sets the grab tool. ... same for scale, rotate .. etc. This way experienced users who are familiar with Blender's shortcuts can keep the toolbar hidden and occasionally access them via keys they already know. Notes: - Tools without immediate access auto-assign a key. - Holding Space, moving the cursor and releasing can be used as a quick way to switch tools *(like a pie menu)*. - Arrow keys can also be used to navigate to a different tool - starting from the active tool. **Enable specific Sculpt & Paint Tools: *Various direct keyboard shortcuts*** To make Blender more consistent, we want to the number rows to behave consistently. For this reason, we would like to remove the number keys to switch tools in paint and sculpt mode. However, there will still be ways to use hotkeys for switching tools, just not the number row keys. In Paint & Sculpt modes, the hotkeys will be displayed in the toolbar. Users can also use the space bar to get a quick menu and change tools this way. **Viewpoint Switching: *Numpad numbers & Tilde (~) Pie Menu*** This makes it more consistent, so that the number keys work in a consistent way, both for laptops and desktops. **Switch Workspaces: *Ctrl+Tab (next) & Ctrl+Shift+Tab (previous)*** With Blender 2.8, we are introducing workspaces. We want to make switching between them easy. We want to make it work like switching browser tabs. **Pivot Point: *Period (.) to cycle though them. Hold period (.) to display pie menu with all pivot options*** This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the period key to cycle through pivot options, or they can hold down period to display a pie menu for quick switching. **Orientation: *Comma (,) to cycle though them. Hold comma (,) to display pie menu with all orientation options*** This makes it easier to use, because users only have to remember one shortcut key for this one feature. Users can either use the comma key to cycle through orientation options, or they can hold down comma to display a pie menu for quick switching. Here’s a more concise overview of the changes: |Key|Change|Status| | -- | -- | -- | |Edit Mode |Tab |*done*| |Mode |Tab+drag |*done*| |Sub-modes( Vert/Edge/Face) |1, 2, 3 |*done*| |Search| TIlde or F3 |*done*| |Active Tool Switching| Space |*done*| |Workspaces Switching | Ctrl+Tab & Ctrl+Shift+Tab |*done*| |Pivot Switch| Period (.) | |Orientation Switch| Comma (,) | |Viewpoint Switching | Numpad Numbers & Tilde key (~) Pie menu|*done* |Collections Switching | Dash (-) | |Favourites Menu| Q |*done*| |Context Sensitive Menu| W |*done*| **Current Blender Keymap Inconsistencies** Anton Atnoguzin mailed us with a list of inconsistencies in Blender's current keymap. Here's a list: ||*Current Inconsistency*|*Similar To*|*Fix*|*Status*| | -- | -- | -- | -- | -- | |Image Editor|Unwrap: **E**|3D View Unwrap (U) |**U**|*done*| |Mesh Edit Mode|Vertex Ungroup: **None**|Object Mode Ungroup (Ctrl-Alt-G) |**Ctrl-Alt-G**|*done*| ||Select Mirror: **None**|Pose Mode Select Mirror (Ctrl-Shift-M) |**Ctrl-Shift-M**|*done*| |Lattice Edit|Proportional Edit Connected: **None**|Proportional Edit Connected (Alt-O)|**Alt-O**|*development needed*| ||Flip **Ctrl-F**|Switch Direction (Armature) & Flip Quats (Pose) (Alt-F)|**Alt-F**|*done*| |Pose Mode|Flip Activate/Selected Bone: **Shift-Ctrl-F**|Select Mirror (Shift-Ctrl-M)|**Shift-Ctrl-M**|*done*| |Dopesheet|Sample Keyframes: **Shift-O**|Conflicts with Proportional Edit Profile (Shift-O)|**Shift-Alt-O**|*done*| ||Mirror: **Shift-M**|Mirror: (Ctrl-M)|**Ctrl-M**|*done*| |Graph Editor|Sample Keyframes: **Shift-O**|Conflicts with Proportional Edit Profile (Shift-O)|**Shift-Alt-O**|*done*| ||Mirror: **Shift-M**|Mirror: (Ctrl-M)|**Ctrl-M**|*done*| |Node Editor|Ungroup: **Alt-G**|Ungroup(Ctrl-Alt-G)|**Ctrl-Alt-G**|*done*| |Animation Channels|Ungroup: **Alt-G**|Ungroup(Ctrl-Alt-G)|**Ctrl-Alt-G**|*done*| |NLA|Add Meta-Strip: **Shift-G**|Add Meta Strip (Sequencer): (Ctrl-G)|**Ctrl-G**|*done*| ||Remove Meta Strips: **Alt-G**|Remove Meta Strip (Sequencer): (Ctrl-Alt-G)|**Ctrl-G**|*done*| |Particle Mode|Tools: **None**|Paint Tools (Various)|**Various**| |Outliner|Add Driver: **D**|Add Driver (Ctrl-D)|**Ctrl-D**|*done*| ||Remove Driver: **Alt-D**|Add Driver (Ctrl-Alt-D)|**Ctrl-Alt-D**|*done*| ||Duplicate Object: **None**|Duplicate Object (Shift-D)|**Shift-D**|*development needed*| ||Duplicate Object Linked: **None**|Duplicate Object Linked (Alt-D)|**Alt-D**|*development needed*| |Clip Editor|Center Current Frame **Numpad Period (.)**|Center Current Frame (Numpad 0)|**Numpad 0**|*done*| |Sequencer|UnMeta Strip **Alt-G**|Ungroup (Ctrl-Alt-G)|**Ctrl-Alt-G**|*done*| **Mac Keymap** We want to improve support for Mac keyboards in two ways: - We want to globally support the Cmd key in addition to Ctrl - We want to support Backspace for Delete
William Reynish self-assigned this 2018-05-23 14:19:52 +02:00
Added subscribers: @WilliamReynish, @pablovazquez, @ideasman42

Added subscriber: @michaelknubben

Added subscriber: @michaelknubben

Added subscriber: @L0Lock

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 :

  • Rendering
  • Baking
  • Animation playback (already have it's own shortcuts anyway)
Something pointed out on [that RCS topic ](https://blender.community/c/rightclickselect/r8bbbc/make-esc-only-cancel-one-task-at-a-time), 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 : - Rendering - Baking - Animation playback (already have it's own shortcuts anyway)

Added subscriber: @AndrewPalmer

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.

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

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.

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

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

@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.

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.
Contributor

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
Contributor

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 :)

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

Added subscriber: @jpthrash

Totally agree with rawalanche, 1-Vertex, 2-Edge, 3-Face, 4-Object, 5-Sculpt... feels more natural imo.

Totally agree with rawalanche, 1-Vertex, 2-Edge, 3-Face, 4-Object, 5-Sculpt... feels more natural imo.

Added subscriber: @dark999

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

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

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.

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

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.

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

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.

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.

  • Pose-Mode, Grease Pencil Edting - are missing from the list.
  • Not sure we should give vertex/edge/face their own number keys.
It's limited to edit-mesh, would we do the same for other modes? *(particle also has selection modes similar to mesh, would we support sub-modes for particle editing... also how would this be used in the UV window?)*.
  • If you mix multiple modes at once (vertex/edge/face), will there be a way to enter edit-mode without loosing the mode you had set?

Also...

  • How to handle having more than 10 modes? (which seems likely since you're already mapped nearly all keys).
  • How to these keys be set when using non mesh objects?
  • Not sure Search needs to be Tab (a very prominent key), we could use an F-Key for example.
Regarding number keys for modes. - Pose-Mode, Grease Pencil Edting - are missing from the list. - Not sure we should give vertex/edge/face their own number keys. ``` It's limited to edit-mesh, would we do the same for other modes? *(particle also has selection modes similar to mesh, would we support sub-modes for particle editing... also how would this be used in the UV window?)*. ``` - If you mix multiple modes at once (vertex/edge/face), will there be a way to enter edit-mode without loosing the mode you had set? Also... - How to handle having more than 10 modes? (which seems likely since you're already mapped nearly all keys). - How to these keys be set when using non mesh objects? - Not sure Search needs to be Tab (a very prominent key), we could use an F-Key for example.

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.

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.
Contributor

In #55162#504930, @ideasman42 wrote:
Regarding number keys for modes.

  • Pose-Mode, Grease Pencil Edting - are missing from the list.

  • Not sure we should give vertex/edge/face their own number keys.

    It's limited to edit-mesh, would we do the same for other modes? (particle also has selection modes similar to mesh, would we support sub-modes for particle editing... also how would this be used in the UV window?).

  • If you mix multiple modes at once (vertex/edge/face), will there be a way to enter edit-mode without loosing the mode you had set?

Also...

  • How to handle having more than 10 modes? (which seems likely since you're already mapped nearly all keys).
  • How to these keys be set when using non mesh objects?
  • Not sure Search needs to be Tab (a very prominent key), we could use an F-Key for example.

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.

> In #55162#504930, @ideasman42 wrote: > Regarding number keys for modes. > > - Pose-Mode, Grease Pencil Edting - are missing from the list. > - Not sure we should give vertex/edge/face their own number keys. > > It's limited to edit-mesh, would we do the same for other modes? *(particle also has selection modes similar to mesh, would we support sub-modes for particle editing... also how would this be used in the UV window?)*. > - If you mix multiple modes at once (vertex/edge/face), will there be a way to enter edit-mode without loosing the mode you had set? > > Also... > > - How to handle having more than 10 modes? (which seems likely since you're already mapped nearly all keys). > - How to these keys be set when using non mesh objects? > - Not sure Search needs to be Tab (a very prominent key), we could use an F-Key for example. 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

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 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.

@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.
Contributor

@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.

@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?

@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?
Contributor

In #55162#504971, @ManuelGrad wrote:
@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?

> In #55162#504971, @ManuelGrad wrote: > @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.

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.

@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

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 ?

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.

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)

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?

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 ?

I'm lost, Grease Pencil is an editor or not? GP needed an editor shortcut ?

Added subscriber: @xrg

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

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
Contributor

In #55162#504999, @WilliamReynish wrote:
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.

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?

modesel.png

> In #55162#504999, @WilliamReynish wrote: > 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. 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? ![modesel.png](https://archive.blender.org/developer/F3446870/modesel.png)

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" ?

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.

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.

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.

In #55162#505096, @thornydre wrote:
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?

> In #55162#505096, @thornydre wrote: > 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?

In #55162#505097, @dark999 wrote:
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.

> In #55162#505097, @dark999 wrote: > 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.

In #55162#505015, @dark999 wrote:
I'm lost, Grease Pencil is an editor or not? GP needed an editor shortcut ?

In #55162#505095, @YAFU wrote:
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.

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

> In #55162#505015, @dark999 wrote: > I'm lost, `Grease Pencil is an editor` or not? GP needed an editor shortcut ? > In #55162#505095, @YAFU wrote: > 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. 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

In #55162#505099, @mendio wrote:

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?

> In #55162#505099, @mendio wrote: > > 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

Removed subscriber: @Traverso

Note that grease pencil branch has many more modes in the branch greasepencil-object

	{OB_MODE_GPENCIL_EDIT, "GPENCIL_EDIT", ICON_EDITMODE_HLT, "Edit Mode", "Edit Grease Pencil Strokes"},
	{OB_MODE_GPENCIL_SCULPT, "GPENCIL_SCULPT", ICON_SCULPTMODE_HLT, "Sculpt Mode", "Sculpt Grease Pencil Strokes"},
	{OB_MODE_GPENCIL_WEIGHT, "GPENCIL_WEIGHT", ICON_WPAINT_HLT, "Weight Paint", "Grease Pencil Weight Paint Strokes"},
	{OB_MODE_GPENCIL_PAINT, "GPENCIL_PAINT", ICON_GREASEPENCIL, "Draw", "Paint Grease Pencil Strokes"},

So we should probably re-use keys for mesh modes for grease pencil (the active object can define which mode is entered).

Note that grease pencil branch has many more modes in the branch `greasepencil-object` ``` {OB_MODE_GPENCIL_EDIT, "GPENCIL_EDIT", ICON_EDITMODE_HLT, "Edit Mode", "Edit Grease Pencil Strokes"}, {OB_MODE_GPENCIL_SCULPT, "GPENCIL_SCULPT", ICON_SCULPTMODE_HLT, "Sculpt Mode", "Sculpt Grease Pencil Strokes"}, {OB_MODE_GPENCIL_WEIGHT, "GPENCIL_WEIGHT", ICON_WPAINT_HLT, "Weight Paint", "Grease Pencil Weight Paint Strokes"}, {OB_MODE_GPENCIL_PAINT, "GPENCIL_PAINT", ICON_GREASEPENCIL, "Draw", "Paint Grease Pencil Strokes"}, ``` So 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

@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

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.

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.

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.
Contributor

In #55162#505355, @ideasman42 wrote:
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.

> In #55162#505355, @ideasman42 wrote: > 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.

**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

Added subscriber: @jenkm
  1. 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.

  2. 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.

  3. It would be nice to have hotkeys for quick toggle visibilty of Subdivision Surface modifier.

  4. Also, currently there is a conflict between Control Point Row (Curve) and Repeat Last, both [Shift-R].

1. 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. 2. I like how the second press of - [x] key switches to the Edge Slide. Similarly, for example, a second press of - [x] can switch Scale to Shrink/Fatten or Push/Pull. 3. It would be nice to have hotkeys for quick toggle visibilty of Subdivision Surface modifier. 4. 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

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

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...

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

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.

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

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".

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

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

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.

I just saw the new update [video ](https://www.youtube.com/watch?v=TK3tgfPZ9SQ) 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

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 AKEY once or twice?”.

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 `AKEY` once or twice?”.

Added subscriber: @Rusculleda

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?

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?

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

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

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

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.

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: @DuarteRamos

Added subscriber: @wevon-2

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.

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

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.

blenderhotkaysproposalaxelmening.png
sorry for my english

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`. ![blenderhotkaysproposalaxelmening.png](https://archive.blender.org/developer/F3516388/blenderhotkaysproposalaxelmening.png) 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.

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

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 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.

Updated keymap so mode-switching numbers group paint modes.

Added subscriber: @antoniov

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.

@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.

Antonio: Great! As long as they are consistent with the regular Blender keys, that's good.

Added subscriber: @ninthjake

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.

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

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.

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.

we've already got the tool shelf over there on the left.

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.

> we've already got the tool shelf over there on the left. 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

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.

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

@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

In #55162#506792, @ideasman42 wrote:

we've already got the tool shelf over there on the left.

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.

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.

> In #55162#506792, @ideasman42 wrote: >> we've already got the tool shelf over there on the left. > > 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. 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

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.

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

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.

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 :

  • L key on a collection in the outliner to select the objects inside the collection
  • TAB key in a node editor could bring the menu to search (instead of SHIFT + A and click on Search)
I was thinking about too little shortcuts that might be useful : - L key on a collection in the outliner to select the objects inside the collection - TAB key in a node editor could bring the menu to search (instead of SHIFT + A and click on Search)

Added subscriber: @moisessalvador

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.

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

Removed subscriber: @moisessalvador

Added subscriber: @orustammanapov

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.

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).

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.

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

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!

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!
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

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'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.

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

Added subscriber: @AlbertoVelazquez

In #55162#507550, @WilliamReynish wrote:
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.

Ah, well, if someone decides that wireframe mode isn't necessary....

> In #55162#507550, @WilliamReynish wrote: > 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. Ah, well, if someone decides that wireframe mode isn't necessary....

Added subscriber: @DotBow

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.

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?

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.

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.

"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.
Sem Título-1.png
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!

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. ![Sem Título-1.png](https://archive.blender.org/developer/F3597334/Sem_Título-1.png) 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.

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

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)

Keymaps.gif

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...

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) ![Keymaps.gif](https://archive.blender.org/developer/F3545124/Keymaps.gif) **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 active**and **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 Window**where 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...

In #55162#507550, @WilliamReynish wrote:
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.

Oh my nono no, no! don't eschew Wireframe, please! That is one of my sanity tools in heavy complex architectural scenes.
Wireframe_Z.gif

> In #55162#507550, @WilliamReynish wrote: > 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. Oh my nono no, no! don't eschew Wireframe, please! That is one of my sanity tools in heavy complex architectural scenes. ![Wireframe_Z.gif](https://archive.blender.org/developer/F3545163/Wireframe_Z.gif)

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:

Numpad Plus, Numpad Minus PageUp, PageDown Trackpad Pan
Edge Slide (Even mode, change control edge) - - -
Proportional Edit (Diameter) - + +
Circle Select (Diameter) + (works with lags) - +
Loop Cut (Number of cuts) + + +
# 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: | | Numpad Plus, Numpad Minus | PageUp, PageDown | Trackpad Pan | | -- | -- | -- | -- | | Edge Slide (Even mode, change control edge) | - | - | - | | Proportional Edit (Diameter) | - | + | + | | Circle Select (Diameter) | + *(works with lags)* | - | + | | Loop Cut (Number of cuts) | + | + | + |

Added subscriber: @MadMinstrel

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.

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

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](https://archive.blender.org/developer/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...

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...

In #55162#509055, @jeacom wrote:
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.

> In #55162#509055, @jeacom wrote: > 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.

In #55162#509055, @jeacom wrote:
Holly thanks @ideasman42 !!
Now we dont have motives to complaint.

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.

> In #55162#509055, @jeacom wrote: > Holly thanks @ideasman42 !! > Now we dont have motives to complaint. 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:
image.png

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: ![image.png](https://archive.blender.org/developer/F3618361/image.png)

In #55162#509085, @JoshStrawbridge wrote:

In #55162#509055, @jeacom wrote:
Holly thanks @ideasman42 !!
Now we dont have motives to complaint.

not sure what new patch notes you read.
search just gets farther out of reach, 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 is perfectly fine and most 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.

i don't see how 2 doesn't work just as well for these functions as tab did when the only thing i could find that 2 did in any of these other editors was that it 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 or having a multicam strip selected in their specific editor.

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

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.
all the other instances of 2 being used easily carried over to the new tool quick swaps in the 3d view for various modes.

What about search be activated by Enter when no other operator is active?

> In #55162#509085, @JoshStrawbridge wrote: >> In #55162#509055, @jeacom wrote: >> Holly thanks @ideasman42 !! >> Now we dont have motives to complaint. > > not sure what new patch notes you read. > search just gets farther out of reach, 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 is perfectly fine and most 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. > > i don't see how 2 doesn't work just as well for these functions as tab did when the only thing i could find that 2 did in any of these other editors was that it 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 or having a multicam strip selected in their specific editor. > > 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 > > 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. > all the other instances of 2 being used easily carried over to the new tool quick swaps in the 3d view for various modes. What about search be activated by Enter when no other operator is active?

Added subscriber: @Januz

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.

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

  • press space => SearchBar
  • long press space => New toolbar
Use that new feature to the searchbar - press space => SearchBar - long press space => New toolbar

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..

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..

In #55162#509171, @AlbertoVelazquez wrote:
Use that new feature to the searchbar

  • press space => SearchBar
  • long press space => New toolbar

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.

> In #55162#509171, @AlbertoVelazquez wrote: > Use that new feature to the searchbar > > - press space => SearchBar > - long press space => New toolbar 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 30cd35a37b

Update: we're testing using tab to toggle editmode as well as dragging for pie-menus: see 30cd35a37b

Added subscriber: @kebrus

Added 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:

  • Isn't one of purposes of the number keys to switch being modes and sub-modes now? Then what is the "view", "paint" and "mask" modes in the Image editor? You decided to have a static horizontal bar to share information between panels, yet in many panels there's nothing useful for them, which in turn means that whatever shortcut you come up to use for this bar automatically gets bounded to it and can't easily and consistently be used in context to the panel you are working in. If I'm using the UV/image editor the numbers change slots, which is fine but then one of the first things I tried was using the 1 to 3 keys to change the mode in the image editor because I got the wrong impression that the paint mode was a mode for the image editor just like the object mode is a mode for the 3d view port? Why do we need a static bar which in most modes gets empty and wastes space and then then you can't change modes when the shortcut key defined for it is being used for something else? Before I could tab between edit and object mode while working in the image editor. Now it does nothing because the concept of a mode doesn't seem clear here. At the very least can someone tell me what is a "mode" in blender?
  • I always thought the tab key was a missing opportunity. It's one of the easiest keys to use and while I do use it a lot when modelling, it's use would almost vanish in other cases. One case where I always thought the tab key could be more useful was when I had to do rigging or animation. Here I would use ctrl+tab often when weighting or posing but not so much single tab because the editing process of the mesh should be complete at this stage. Could the tab key be used to quickly switch between the last two modes perhaps? Cycle through them maybe? For instance, what if ctrl+tab changes how single tab works? Like, ctrl+tab to cycle whatever mode you want to edit with single tab. These are just some ideas... Whatever is the case the current state is still inconsistent. When using a text field you can cycle through them as usual using tab, however, for some reason, this is not true for dropdowns, buttons, etc... In windows you can control every single element using keyboard keys using: tab, shift tab,space, enter, arrows, etc. In blender you are forced to use arrow keys and... they are Inverted??? what bad joke is this??? What is the meaning of having tab to open a dropdown you cant then cycle between the options using tab? What is the meaning of opening the operator menu with f6 to then drop the mouse to use the arrow keys only to be surprised that up is down, down is up, space cant be used and whenever you use enter to position resets??? There are wild inconsistencies here and having tab opening a search limits and hinders any possible solutions.

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

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: - Isn't one of purposes of the number keys to switch being modes and sub-modes now? Then what is the "view", "paint" and "mask" modes in the Image editor? You decided to have a static horizontal bar to share information between panels, yet in many panels there's nothing useful for them, which in turn means that whatever shortcut you come up to use for this bar automatically gets bounded to it and can't easily and consistently be used in context to the panel you are working in. If I'm using the UV/image editor the numbers change slots, which is fine but then one of the first things I tried was using the 1 to 3 keys to change the mode in the image editor because I got the wrong impression that the paint mode was a mode for the image editor just like the object mode is a mode for the 3d view port? Why do we need a static bar which in most modes gets empty and wastes space and then then you can't change modes when the shortcut key defined for it is being used for something else? Before I could tab between edit and object mode while working in the image editor. Now it does nothing because the concept of a mode doesn't seem clear here. At the very least can someone tell me what is a "mode" in blender? - I always thought the tab key was a missing opportunity. It's one of the easiest keys to use and while I do use it a lot when modelling, it's use would almost vanish in other cases. One case where I always thought the tab key could be more useful was when I had to do rigging or animation. Here I would use ctrl+tab often when weighting or posing but not so much single tab because the editing process of the mesh should be complete at this stage. Could the tab key be used to quickly switch between the last two modes perhaps? Cycle through them maybe? For instance, what if ctrl+tab changes how single tab works? Like, ctrl+tab to cycle whatever mode you want to edit with single tab. These are just some ideas... Whatever is the case the current state is still inconsistent. When using a text field you can cycle through them as usual using tab, however, for some reason, this is not true for dropdowns, buttons, etc... In windows you can control every single element using keyboard keys using: tab, shift tab,space, enter, arrows, etc. In blender you are forced to use arrow keys and... they are Inverted??? what bad joke is this??? What is the meaning of having tab to open a dropdown you cant then cycle between the options using tab? What is the meaning of opening the operator menu with f6 to then drop the mouse to use the arrow keys only to be surprised that up is down, down is up, space cant be used and whenever you use enter to position resets??? There are wild inconsistencies here and having tab opening a search limits and hinders any possible solutions. # 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.

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.

In #55162#509176, @kebrus wrote:
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.

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?

> In #55162#509176, @kebrus wrote: >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. 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?

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?

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.

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.

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.

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.

There is some competition for easily accessible keys at the moment.

I would have preferred to make search the Accent/Grave key (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.

Some UI and Keymap changes seem like pop out of nowhere, without foundation or explanation.

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.

> 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? 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. > 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. 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. > 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. There is some competition for easily accessible keys at the moment. I would have preferred to make search the `Accent/Grave` key (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](https://archive.blender.org/developer/P720.txt). > Some UI and Keymap changes seem like pop out of nowhere, without foundation or explanation. 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.

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.

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

Added subscriber: @JonDoe286

You should be aware that is impossible to access Accent/Grave key easily in other keyboard that one with english layout

You should be aware that is impossible to access Accent/Grave key easily in other keyboard that one with english layout

In #55162#509184, @ideasman42 wrote:
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.

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.

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.

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.

> In #55162#509184, @ideasman42 wrote: > 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. 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. > 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. 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.

In #55162#509494, @mendio wrote:
You should be aware that is impossible to access Accent/Grave key easily in other keyboard that one with english layout

I agree and this is already reported and discussed

> In #55162#509494, @mendio wrote: > You should be aware that is impossible to access Accent/Grave key easily in other keyboard that one with english layout I agree and this is already reported and discussed

In #55162#508399, @MadMinstrel wrote:
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.

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

> In #55162#508399, @MadMinstrel wrote: > 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. **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 suggesting**my** 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 on**Spacebar**. **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

Current State (testing)

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

Tab: Edit-mode toggle.
Tab + Cursor Drag: mode switching pie menu.
Accent/Grave: Search
Accent/Grave + Cursor Drag: for 3D view pie menu.
1..3, Shift-1..3: Edit mesh vertex/edge/face toggle.
Space: toolbar modifier

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

Screenshot (626).png

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.

Screenshot (627).png

Screenshot (628).png

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.

Screenshot (629).png

Hope it makes sense. :) Thanks Guys. Keep up the Amazing Work.

> Current State (testing) > > For now this shows the new keymap for people who want to use 2.8 > > Tab: Edit-mode toggle. > Tab + Cursor Drag: mode switching pie menu. > Accent/Grave: Search > Accent/Grave + Cursor Drag: for 3D view pie menu. > 1..3, Shift-1..3: Edit mesh vertex/edge/face toggle. > Space: toolbar modifier 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** ![Screenshot (626).png](https://archive.blender.org/developer/F3634358/Screenshot__626_.png) 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. ![Screenshot (627).png](https://archive.blender.org/developer/F3634376/Screenshot__627_.png) ![Screenshot (628).png](https://archive.blender.org/developer/F3634380/Screenshot__628_.png) 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. ![Screenshot (629).png](https://archive.blender.org/developer/F3634513/Screenshot__629_.png) Hope it makes sense. :) Thanks Guys. Keep up the Amazing Work.
Contributor

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.

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.

In #55162#509678, @Rawalanche wrote:
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".

> In #55162#509678, @Rawalanche wrote: > 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.

~ Tilde is also a "Dead key" with the US international keyboard layout, so its usage as proposed in Blender isn't ideal.

In #55162#509727, @s12a wrote:
~ 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.

> In #55162#509727, @s12a wrote: > ~ 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*

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.

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.

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.

In #55162#509770, @WilliamReynish wrote:
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

> In #55162#509770, @WilliamReynish wrote: > 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

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.

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.

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!

that's lovely. again thanks for all the amazing work guys!

In #55162#509875, @WilliamReynish wrote:
Yes, that's already what we are thinking too, to add pie menus to Pivot, Orientation and Proportional Edit.

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.

sub-object-pie.jpg

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.

> In #55162#509875, @WilliamReynish wrote: > Yes, that's already what we are thinking too, to add pie menus to Pivot, Orientation and Proportional Edit. 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. ![sub-object-pie.jpg](https://archive.blender.org/developer/F3648003/sub-object-pie.jpg) 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?

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.

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

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.

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?

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: @Djay

Added subscriber: @Datross

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.

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

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

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.

Search.PNG

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. ![Search.PNG](https://archive.blender.org/developer/F3742113/Search.PNG)
  • Should we update the keymap for what is currently in 2.8?
  • Should we add 1..9 keys for brushes or reserve them for future use?
- Should we update the keymap for what is currently in 2.8? - Should we add 1..9 keys for brushes or reserve them for future use?

In #55162#513408, @ideasman42 wrote:

  • Should we update the keymap for what is currently in 2.8?
  • Should we add 1..9 keys for brushes or reserve them for future use?

Reserve for brushes please!

> In #55162#513408, @ideasman42 wrote: > - Should we update the keymap for what is currently in 2.8? > - Should we add 1..9 keys for brushes or reserve them for future use? Reserve for brushes please!

Added subscriber: @wv0je

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)

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-X followed by one or more keys, also CTRL-C is a prefix reserved for user-defined sequences. And ALT-X is used to enter commands by typing their name.

Not that I’m saying that Blender is the Emacs of CG software ... ;)

Does Blender need to go to multi-key sequences? E.g. in Emacs we have `CTRL-X` followed by one or more keys, also `CTRL-C` is a prefix reserved for user-defined sequences. And `ALT-X` is used to enter commands by typing their name. Not that I’m saying that Blender is the Emacs of CG software ... ;)

Added subscriber: @portnov

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.

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-A does.

I notice that INS is not defined for any purpose outside the Text Editor; how about using it for the Add function in the 3D Viewport?

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-A` does. I notice that `INS` is not defined for any purpose outside the Text Editor; how about using it for the Add function in the 3D Viewport?

Ins could be added as well as Shift-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 all

`Ins` could be added as well as `Shift-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 all

They must find it hard to toggle the overwrite mode in the text editor, then, since that operator is not bound to any other key.

They 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.

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.

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_grave in the Armature and Pose keymaps.

Ah, just noticed `ctrl-accent_grave` in 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.

By accent-grave, do you mean the Tilde key? It is used for viewport switching, but only works on Linux atm.

ACCENT_GRAVE is the name used in the RNA.

`ACCENT_GRAVE` is 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_Popup_2.7X.png

Set Origin Hotkey Command 2.7X

Set_Origin_Hotkey_2.7X.png

Set Origin Hotkey Command 2.8 Minimal

Set_Origin_Hotkey_2.8_Minimal.png

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

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_Popup_2.7X.png](https://archive.blender.org/developer/F3854245/Set_Origin_Popup_2.7X.png) Set Origin Hotkey Command 2.7X ![Set_Origin_Hotkey_2.7X.png](https://archive.blender.org/developer/F3854253/Set_Origin_Hotkey_2.7X.png) Set Origin Hotkey Command 2.8 Minimal ![Set_Origin_Hotkey_2.8_Minimal.png](https://archive.blender.org/developer/F3854256/Set_Origin_Hotkey_2.8_Minimal.png) 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

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.

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 AKEY to always mean “select all” while AKEY twice 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...)

Separate keystrokes for unconditional-select-all versus unconditional-select-none -- Yes! Good idea. Alternatively: is it possible for `AKEY` to always mean “select all” while `AKEY` twice 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-W is still assigned to wm.save_mainfile. Has everybody got used to typing CTRL-S instead? Can we reassign CTRL-W to something else yet?

It appears that `CTRL-W` is still assigned to `wm.save_mainfile`. Has everybody got used to typing `CTRL-S` instead? Can we reassign `CTRL-W` to something else yet?

In #55162#515096, @WilliamReynish wrote:
By accent-grave, do you mean the Tilde key? It is used for viewport switching, but only works on Linux atm.

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.


In #55162#515479, @portnov wrote:
Hi all.
About Tab+mouse drag: it is interesting feature, but it is very easy to enter this mode and accidentally select something by just accidentally 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.

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).


In #55162#515518, @ldo wrote:
Separate keystrokes for unconditional-select-all versus unconditional-select-none -- Yes! Good idea.

Alternatively: is it possible for AKEY to always mean “select all” while AKEY twice in quick succession always means “select none”? In other words, add new timing-based multi-keystroke behavior, analogous to multiple mouse-button clicks? This would still get us away from the current toggle behavior, while doing minimal violence to everybody’s existing muscle memory. (And open up a new vista of future keystroke options...)

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.


In #55162#515520, @ldo wrote:
It appears that CTRL-W is still assigned to wm.save_mainfile. Has everybody got used to typing CTRL-S instead? Can we reassign CTRL-W to something else yet?

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.

> In #55162#515096, @WilliamReynish wrote: > By accent-grave, do you mean the Tilde key? It is used for viewport switching, but only works on Linux atm. 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. ---- > In #55162#515479, @portnov wrote: > Hi all. > About Tab+mouse drag: it is interesting feature, but it is very easy to enter this mode and accidentally select something by just accidentally 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. 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). ---- > In #55162#515518, @ldo wrote: > Separate keystrokes for unconditional-select-all versus unconditional-select-none -- Yes! Good idea. > > Alternatively: is it possible for `AKEY` to always mean “select all” while `AKEY` twice in quick succession always means “select none”? In other words, add new timing-based multi-keystroke behavior, analogous to multiple mouse-button clicks? This would still get us away from the current toggle behavior, while doing minimal violence to everybody’s existing muscle memory. (And open up a new vista of future keystroke options...) 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. ---- > In #55162#515520, @ldo wrote: > It appears that `CTRL-W` is still assigned to `wm.save_mainfile`. Has everybody got used to typing `CTRL-S` instead? Can we reassign `CTRL-W` to something else yet? 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. :)

Select_More_Less.png

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,

Toggle_Select_A.png

  1. Had to go through the entire list for the 'A' key and disable all the 'Alt A' listings.
  2. Had to expand each & every listing for the 'A' key and change it from 'Select' back to 'Toggle'.
  3. Thought I could set the preset to 'Blender 2.7X' and just change the few keys I needed without going through the entire list of 'A' & 'Alt A's. --- Wasn't that helpful given that changes to the 'A' key not being a toggle seemed to be global? And the 2.7X keymap doesn't carry the goodies from the new Default. (New F1-F4 Keys, Tab-Drag Mode Pies, Etc.)

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

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. :) ![Select_More_Less.png](https://archive.blender.org/developer/F3862015/Select_More_Less.png) 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, ![Toggle_Select_A.png](https://archive.blender.org/developer/F3862169/Toggle_Select_A.png) 1. Had to go through the entire list for the 'A' key and disable all the 'Alt A' listings. 2. Had to expand each & every listing for the 'A' key and change it from 'Select' back to 'Toggle'. 3. Thought I could set the preset to 'Blender 2.7X' and just change the few keys I needed without going through the entire list of 'A' & 'Alt A's. --- Wasn't that helpful given that changes to the 'A' key not being a toggle seemed to be global? And the 2.7X keymap doesn't carry the goodies from the new Default. *(New F1-F4 Keys, Tab-Drag Mode Pies, Etc.)* 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

About Tab+mouse drag: it is interesting feature, but it is very easy to enter this mode and accidentally select something by just accidentally 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.

Forcing to wait will slow down peoples workflow (generally find it annoying),

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??

>About Tab+mouse drag: it is interesting feature, but it is very easy to enter this mode and accidentally select something by just accidentally 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. > Forcing to wait will slow down peoples workflow (generally find it annoying), 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: 72e090a3cf

  Keymap: Remove pie menu from tab-key
  
  Based on discussion with @eyecandy & @venomgfx,
  we agreed that Tab drag/click, is too easy to accidentally press
  while moving the cursor.
  It's also not typical to activate the operator on release which
  introduces a small lag switching edit-mode.
  
  This is a shame since in some ways its a nice way to re-use the key,
  overall it just feels a little too unpredictable for such an important
  action.
  
  This commit makes the following changes.
  
- Tab: toggles edit-mode.
- Ctrl-Tab: opens pie menu.
- Ctrl-AccentGrave: toggles manipulator.
  
  Note, while AccentGrave isn't always available
  this shortcut is not essential.
Update, tab-drag has been removed in favor of Ctrl-Tab for the pie menu. See: 72e090a3cf ``` Keymap: Remove pie menu from tab-key Based on discussion with @eyecandy & @venomgfx, we agreed that Tab drag/click, is too easy to accidentally press while moving the cursor. It's also not typical to activate the operator on release which introduces a small lag switching edit-mode. This is a shame since in some ways its a nice way to re-use the key, overall it just feels a little too unpredictable for such an important action. This commit makes the following changes. ``` - Tab: toggles edit-mode. - Ctrl-Tab: opens pie menu. - Ctrl-AccentGrave: toggles manipulator. ``` Note, while AccentGrave isn't always available this shortcut is not essential.

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

Backspace doesn’t seem to be used for anything in the 3D View (except for edit mode for font objects). And it’s a nice, large key; [easy to hit](https://en.wikipedia.org/wiki/Fitts%27s_law).

Removed subscriber: @MadMinstrel

Removed subscriber: @MadMinstrel

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

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.

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.


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

  • Press spacebar + press letter = Active tool shortcut

  • Press spacebar + release space + begin to write = searchbar

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

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

@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. ---- > In #55162#515683, @AlbertoVelazquez wrote: > I want to ask if developers have though in some way to make easy to access to search (actual option in edit menu is really hide). Like, for example, to put a searchbox inside new active tools toolbar with this behaviour > > - Press spacebar + press letter = Active tool shortcut > > - Press spacebar + release space + begin to write = searchbar > > It's weird some actual behaviour and shortcuts of the activetools toolbar, like after press space you need to press other hotkey (Ctrl+B) to select one active tool. I don't that newbies will learn this type of behaviours and old user will configure their own hotkeys or only the menu. From recent experience, drawing distinctions between subtle changes in behavior tends to be confusing & annoying. It also makes switching tools significantly worse.

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

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

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

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

image.png

image.png

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. ![image.png](https://archive.blender.org/developer/F3863615/image.png) ![image.png](https://archive.blender.org/developer/F3863657/image.png)

Mockup

image.png

Mockup ![image.png](https://archive.blender.org/developer/F3863952/image.png)

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

Tab_Press.png

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 ![Tab_Press.png](https://archive.blender.org/developer/F3864597/Tab_Press.png)

In #55162#515710, @AlbertoVelazquez wrote:
Mockup

image.png

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


In #55162#515761, @JonDoe286 wrote:
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

Tab_Press.png

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

> In #55162#515710, @AlbertoVelazquez wrote: > Mockup > > ![image.png](https://archive.blender.org/developer/F3863952/image.png) This breaks using accelerator keys to access tools, which is the main purpose of having it accessible from a key. ---- > In #55162#515761, @JonDoe286 wrote: > 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 > > ![Tab_Press.png](https://archive.blender.org/developer/F3864597/Tab_Press.png) How do you prevent the press event from being used before the drag event activates?

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

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

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

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

  • We want to support Backspace for Delete

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

Looking over this task and there are some remaining things I'm unsure of. > We want to improve support for Mac keyboards in two ways: > > - We want to globally support the Cmd key in addition to Ctrl Could we run a post process that duplicates all the key-bindings that use Ctrl? > - We want to support Backspace for Delete Why? We already have 'X' key for delete. Having 3 keys for the same thing seems excessive. (Especially if you multiply out all the combinations used with modifier keys)

In #55162#515801, @ideasman42 wrote:
How do you prevent the press event from being used before the drag event activates?

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

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

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

> In #55162#515801, @ideasman42 wrote: > How do you prevent the press event from being used before the drag event activates? Hmmm. I was trying both ways out. Tab as Click or Press. Although it seemed snappier, there was a difference I couldn't really wrap my finger around. I think it's exactly what you mentioned Campbell. When I set Tab to Press instead of Click. Each time I 'Hold' the Tab key and Drag-Mouse for Pie Menu. It activated the Edit Mode Toggle as well. Seems this doesn't happen with the 'Click' method. So holding down Tab doesn't activate the Toggle Edit Mode command. And moving the mouse activates the pie menu without disturbing the current selected mode of the object. *(But you already knew that. :D)* Guess that's the beauty of experimentation eh? Learn something new everyday. Thanks for clearing it up for me. Was a bit overly enthusiastic with my findings it seems. :D Still, looking forward to keeping Tab + Drag-Mouse for Mode Pie. *(In my personal key config of course.)* I just love it too much and it hasn't obstructed me in my workflow in anyway to justify binding a whole new key combo just for the pie. IMO, Ctrl + Tab can be used for something much more frequently used. Especially when Tab + Drag can do the Pie just fine. But that's just me. :) Thanks man, have a good night. Also great work clearing up almost all those keymap inconsistencies. Didn't even notice until you started fixing them. Cheers.

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

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

In #55162#515822, @JonDoe286 wrote:
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.

> In #55162#515822, @JonDoe286 wrote: > 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.

@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.

In #55162#515826, @orustammanapov wrote:

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

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

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

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

SLAP your hands on

6GcM.gif

> In #55162#515826, @orustammanapov wrote: >> In #55162#515822, @JonDoe286 wrote: >> Also +1. No to 'Backspace' as another delete. Just a waste of a key and completely pointless. Takes away the whole purpose of a 'Default Minimal Keymap'. I think 'X' for 'Workflow' and 'Delete' for 'Standard' is reasons enough. > > Really? It might be only me, but every time before pressing "x" to delete something I keep pressing "Backspace" several times before getting used to "x" again. To me personally it's a mystery why on earth (I'm really exaggerating here) isn't "Ctl/Cmd+a" used to select all objects, like any other application (and every OS) does? But again it might be subjective, I just wished every new user had a luxury to find familiar key bindings like "Ctrl/Cmd+a" to select all, "Ctrl/Cmd+c" to copy, "Ctrl/Cmd+v" to paste, "Ctrl/Cmd+x" to cut, "Ctrl/Cmd+d" to duplicate/clone/link (in some combination with "Alt" and "Shift" keys), and ideally it should be possible to deselect by clicking on empty space in the viewport (complex selections can still be saved in a vertex group in between, so no need to worry about loosing it). It is no big deal to change keyboard shortcuts for experienced user, it is for a newbie who knows nothing about Blender keymap. pressing Cntrl/Cmd + a is really less effective than simply "A" some people dont have the flexibility to stretch the hands on some keys fast or accureately, and for most frequently used commands like "select all" its better to not put muscular pressure, at least your finger joints will last longer... And I will be honest, there is easy way to learn all the key shortcuts of blender really easy. **SLAP your hands on** ![6GcM.gif](https://archive.blender.org/developer/F3866356/6GcM.gif)

"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.

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

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

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

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

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

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

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

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

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

In #55162#515847, @thornydre wrote:
Don't know if it has already been mentioned here, but in the Python console, ctrl+spacebar for maximizing the editor is in conflict with autocompletion.

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

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


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

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


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

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

> In #55162#515847, @thornydre wrote: > Don't know if it has already been mentioned here, but in the Python console, `ctrl+spacebar` for maximizing the editor is in conflict with autocompletion. Thanks for pointing this out, it applies to the text editor too, checked and this prevents the console/text-editor from going fullscreen via a shortcut, thats not great, but not necessarily a blocker IMHO. We had similar conflicts in the past for eg with Ctrl-Left/Right being used to switch screens, getting used by the text editor for cursor navigation (no longer a problem with the new keymap). Looking into this further, we can use Shift-Space for auto-complete, since animation isn't activated from console/text editor, although this would become annoying when typing capital text that contains spaces. ---- > In #55162#515878, @ldo wrote: > Just a note, but this idea that `⌘` should be used on the Mac where other platforms use `CTRL` should have been abandoned long ago. It dates from about 1984-87, before Mac keyboards had `CTRL` keys. (In other words, from before the living memory of most of those reading this.) It makes more sense to treat `⌘` as equivalent to the `SUPER`/`WINDOWS` key. Why not have a preference to swap [OSKey / Ctrl] ? It seems this is what Mac users expect, some extra work would need to go into making key shortcuts display properly. ---- > In #55162#515879, @ldo wrote: > Beware of `CTRL`-`PAGE_UP` and `CTRL`-`PAGE_DOWN` — these would conflict with the keystrokes for adjusting the auto IK chain length. Interestingly, this seems to be hardcoded — I can’t find it in a keymap anywhere. I couldn't find this anywhere, do you have an example of how to use this binding?

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

Control of the Auto IK chain length is documented [here](https:*docs.blender.org/manual/en/dev/rigging/armatures/posing/bone_constraints/inverse_kinematics/introduction.html#automatic-ik). You might remember [this patch](https:*developer.blender.org/D1547) to the relevant docs.

In #55162#515901, @ideasman42 wrote:

In #55162#515847, @thornydre wrote:
Don't know if it has already been mentioned here, but in the Python console, ctrl+spacebar for maximizing the editor is in conflict with autocompletion.

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

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

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

> In #55162#515901, @ideasman42 wrote: >> In #55162#515847, @thornydre wrote: >> Don't know if it has already been mentioned here, but in the Python console, `ctrl+spacebar` for maximizing the editor is in conflict with autocompletion. > > Thanks for pointing this out, it applies to the text editor too, checked and this prevents the console/text-editor from going fullscreen via a shortcut, thats not great, but not necessarily a blocker IMHO. We had similar conflicts in the past for eg with Ctrl-Left/Right being used to switch screens, getting used by the text editor for cursor navigation (no longer a problem with the new keymap). > > Looking into this further, we can use Shift-Space for auto-complete, since animation isn't activated from console/text editor, although this would become annoying when typing capital text that contains spaces. I think that the best would be `tab`, like any other console, but I don't know if it is conflicting with something else, but yes as you said it is not really blocking :)

Good morning everyone. :) Small issue I'm facing. I'm trying to maintain a custom hotkey preset separate from the new default. So whenever the default is being changed/updated (which is the whole point of this task: #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. :)

Keymap_Change_Default_Custom.png

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.

Affinity_Reset.png

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! :)

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. :) ![Keymap_Change_Default_Custom.png](https://archive.blender.org/developer/F3871771/Keymap_Change_Default_Custom.png) 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. ![Affinity_Reset.png](https://archive.blender.org/developer/F3871518/Affinity_Reset.png) 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! :)

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

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


@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.

> In #55162#515920, @thornydre wrote: > I think that the best would be `tab`, like any other console, but I don't know if it is conflicting with something else, but yes as you said it is not really blocking :) If we only make tab auto-complete for the console we would need a different key for the text editor since this is used for indentation. Also the PyConsole supports indentation, although in this case its common to detect initial indentation or typing after existing text. ---- @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.

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

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

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

Added convenience feature for experienced users: Alt-MMB(drag) for view axis switching: 1bf5cc57bd Its for experienced users, of course existing methods for changing view axis remains.

Added subscriber: @JamesPrakashJC

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?

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. :)

@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

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?

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.

@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 QUOTE is not used for anything? I posted a .blendfile which binds QUOTE to select-all and SHIFT-QUOTE to select-none in every editor, just to see how it worked in practice.

Separate keystrokes for select-all versus select-none is a good idea. Is there any reason why `QUOTE` is not used for anything? I [posted a `.blend`file](https://blenderartists.org/t/better-selection-keystrokes/684981) which binds `QUOTE` to select-all and `SHIFT`-`QUOTE` to select-none in every editor, just to see how it worked in practice.

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

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

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".

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.

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. :)

@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.

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 ](https://blenderartists.org/t/smart-delete/678815/30) 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

@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

@JonDoe286, added - Shift + Ctrl + Spacebar

Added subscriber: @bent

Added subscriber: @bent