Page MenuHome

Keymap: use number keys for mode switching (2nd Iteration)
Confirmed, NormalPublicDESIGN

Assigned To
None
Authored By
Tokens
"The World Burns" token, awarded by Alumx."Dislike" token, awarded by madminstrel."Dislike" token, awarded by chironamo."Dislike" token, awarded by dballesg."Dislike" token, awarded by xdanic."Dislike" token, awarded by activemotionpictures."Dislike" token, awarded by 3di."Dislike" token, awarded by AnityEx."Dislike" token, awarded by CobraA."Like" token, awarded by dru4."Dislike" token, awarded by silex."Dislike" token, awarded by Leroy."Dislike" token, awarded by dcvertice."Dislike" token, awarded by xorrito."Dislike" token, awarded by HEYPictures."Dislike" token, awarded by rawalanche."Like" token, awarded by JulienKaspar."Dislike" token, awarded by Stig."Dislike" token, awarded by gilberto_rodrigues."Dislike" token, awarded by finirpar."Love" token, awarded by DaveDeer."Heartbreak" token, awarded by 1D_Inc."Love" token, awarded by baoyu.

Description

Motivation

  • Improve ease of mode switching with direct shortcuts (Tab and Ctrl+Tab functionality remains the same)
  • Consistent accross all object types.
  • Allows the use of pie menus for quickly going into sub-modes (and later adding more options like Island Select mode for meshes)
  • Having the ~ key (or equivalent left to 1) be the Switch Object (Transfer Mode) fits better with mode switching than D.
  • The current functionality of toggling Collections visibility often leads to confusion for new users:
    • Objects seemingly disappear
    • Risk of losing visibility settings or undo steps.

Proposed Solution

This task is to evaluate the possibility of using number keys for mode switching, in addition to the already existing Tab and Ctrl+Tab shortcuts to toggle Edit, Pose, and modes pie menu.

The current proposal:

  • The numbers row will get a dedicated option in the Keymap Preferences:
    • Collection Visibility (default at least during the trial phase)
    • Mode Switching
    • Potentially Emulate Numpad could be part of this option as well.
  • Behavior for Tab and Ctrl-Tab for mode edit-mode switching will be kept as this is convenient and used in many other areas where numbers make less sense (graph-editor, NLA, sequencer... etc, where using numbers doesn't make so much sense).

Details

  • Modes would be mapped to a key consistently between object types, so the pose-mode number-key would do nothing for a curve (for example).
  • Equivalent modes would share a key between object types (grease-pencil Draw to use the same key as mesh Texture Paint, the same goes for Grease Pencil Sculpt, Vertex Paint... etc).
  • Modes to switch include (8): OBJECT EDIT, SCULPT, TEXTURE_PAINT, VERTEX_PAINT, WEIGHT_PAINT, PARTICLE_EDIT, POSE.

Open Topics

Should sub-modes have direct access?

With the introduction of pie menus by default in 2.80, users are now used to these and pie menus could be used to access sub-modes.

It has been proposed in T84380 that vertex/edge/face be expanded into the number buttons too. This only works well for mesh and grease pencil edit-mode, however it has some down-sides.

  • We would be using all number keys by default, any additional modes or sub-modes wont fit.
  • Some sub-modes wont fit:
    • Particle edit (currently uses keys 1-3 to switch sub-modes).
    • Weight paint.
    • Texture/Vertex paint.

The ideal solution in this case isn't clear, either we accept loosing shortcuts for switching sub-modes or accept some inconsistency (having to add a different shortcut for sub-mode switching for modes besides edit-mode).

There are plans to merge painting modes into a single attribute painting mode, even if this is done, it might make sense to expose weight/texture/sculpt as sub-modes... either way, I don't think we should rely on this change unless it's committed to master before the keymap changes. The same applies to the future of Particle Edit once the new Hair object type is implemented.

What to do when pressing a modes key a second time?

Currently nothing is planned. Options are to toggle the mode or cycle through sub-modes. Both have their pro's and con's so there are no plans to use second-time presses.

Is overwriting edit-mesh modes acceptable?

By switching directly into vert/face/edge modes, this will overwrite the mixed modes which the user will need to manually set every time they enter edit-mode. Holding Shift while changing selection modes will extend the selection as it does currently.
Even though this isn't such a common functionality, it would be good to avoid breaking peoples workflows.


Updated by @Pablo Vazquez (pablovazquez) based on notes from the UI meeting on 20 May.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Updated the task description with some notes, mainly:

  • The numbers row will get a dedicated option in the Keymap Preferences:
    • Collection Visibility (default at least during the trial phase)
    • Mode Switching
    • Potentially Emulate Numpad could be part of this option as well?
  • Graphic to easily understand the new mapping
Julian Eisel (Severin) renamed this task from Keymap: use number keys for mode switching to Keymap: use number keys for mode switching (2nd Iteration).May 20 2021, 5:33 PM

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key. Most 60% keyboard layouts will have that key mapped to escape in any keyboard distribution.

Proposed solutions:

  • Map Mode Transfer to the 1 key and shift all shortcuts one key to the right.
  • Replace Object Mode by Mode Transfer in the 1 key and make Tab return to Object Mode when in any other mode.

I really hope that this is just an optional setting, personally feel very confusing, and most of my operations are object mode and editing mode, pie is slower than shortcut keys for me, just like 2.7x ctrl+tab to enter point, line and surface mode.
Using the number keys to switch collections is the best design I have seen. I don’t want to rely too much on the outline editor.

We should focus on the functions that are not available, instead of blindly changing the existing functions.

I really hope that this is just an optional setting,

Yes, it is designed as an optional setting (D11188)

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key. Most 60% keyboard layouts will have that key mapped to escape in any keyboard distribution.

Proposed solutions:

  • Map Mode Transfer to the 1 key and shift all shortcuts one key to the right.
  • Replace Object Mode by Mode Transfer in the 1 key and make Tab return to Object Mode when in any other mode.

I can corroborate. In my country that key literally doesn't exist

Yes, it is designed as an optional setting (D11188)

Thanks for your reply, I can sleep peacefully

To be clear, the design doesn't propose using the ~ key, precisely because using it causes problems. It proposes to use whatever is to the left of the number row (as long as this isn't used already, e.g. Esc). It would be using the physical location.
There will be some (from all I know relatively uncommon) keyboards where there is no usable key there, unfortunately we can't design the keymap to always work for all the different keyboards around...

Maybe we can have some kind of fallback. But on the other hand, the Mode Transfer operator is basically just a shortcut to save some clicks - even if it's super useful in practice. It's a helper not core functionality. With the mode switching numbers the workflow switching mode may become much faster anyway.

Would it be much better if you dubble click on an object to switch on its edit mode. This would be werry nice

Would it be much better if you dubble click on an object to switch on its edit mode. This would be werry nice

Well, it will bring a lot of problems, if to take into account tightly packed assemblies (like an engines models) and multiedit feature.

To be clear, the design doesn't propose using the ~ key.

Sure, it is the best possible option, which is not available for defaults because of problems with tilda key availability. So there is no ability to propose it to defaults, no matter how good it can possibly be.
It was so close, but keyboard manufacturers ruined it...

With the mode switching numbers the workflow switching mode may become much faster anyway.

There are several doubts about it at the concept level.

  1. The problem is that number keys are not self-representative - they represents only numbers, which assignment is changed in dependency of your current mode.

You pressed a number - it's assignment is changed - this number don't represent the same action anymore.
To check what number you have to press to achieve a desired result you have to be sure that your mode is corresponding to expected layout.
As a result you always have to make calculations - to guess or to remember or to check in order to be able to use such kind of a system - until it is memorized to the state of periodic tables or the national anthem.

Look how much graphics from topic you need to remember, then close your eyes and try to remember all of this, every single number and mode - because such graphics will be not presented anywhere except a manual page.
I mean, if some kind of a system require so much graphics, it usually more likely require UI rather than user memory.

  1. Modes switching was never a critical problem.

Of course, it is possible to learn it, but this system will not allow to save the enough amount of an efforts in order to be too much effective to be a lifesaver.
I don't remember people that require that much of Blender modes constantly.
Animators need animation prioritized, Sculptors need sculpting prioritized, most of modellers need object/edit mode transition most of the time.

  1. The problem is that number keys are not self-representative - they represents only numbers, which assignment is changed in dependency of your current mode.

The assignment would not be changed. The proposal is to always have the same mode on the same number, regardless of which mode you are currently in. But not all keys will do something at all times.

But not all keys will do something at all times.

Ok, I see the harmony.
I like the design idea behind it, that it is possible to organize modes like that - where same keys allow to reach the same modes across several objects types.
It looks well organized, a nice design approach to generalize every accessible mode.
Just have some doubds about practical use.

2 of 4 keyboards I'm using in my computers don't have that key.

Can you please specify keyboard model names or pictures?
It is useful to see what is actually available there to avoid guessing during design.

Why not duplicate “Industry Compatible” keymap behavior?
IMO the most convenient keymaps for 1 2 3 4 5 6 7 8 9 (vert, edge, face, object, sculpt, vert paint, weight paint, texture paint, particle)

I can assure you majority of people are going to hate this. This is so off from what the keymaps work like in other software Blender will often be used alongside of.

This continues the usual Blender saga, where already established standards need to be reinvented from scratch and executed in an inferior way.

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key.

This is artificially constructed problem. Blender easily allows to map same operator to multiple different keys, so there's nothing preventing the keymap to have the tilde key operator mapped multiple times also for the keys in place of tilde in other regional keyboard layouts. Also, you are just offloading that problem to a less used feature, but it will still be there when one tries to use that less used feature, it won't go away. But a key that's directly under escape is a very valuable key reach-wise, so mapping it to something not very useful just because it changes in regional keyboard layouts is just lame solution.

I'm really quite neutral on this. As longs as it can be remapped, it's okay =))

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key.

This is artificially constructed problem. Blender easily allows to map same operator to multiple different keys, so there's nothing preventing the keymap to have the tilde key operator mapped multiple times also for the keys in place of tilde in other regional keyboard layouts. Also, you are just offloading that problem to a less used feature, but it will still be there when one tries to use that less used feature, it won't go away. But a key that's directly under escape is a very valuable key reach-wise, so mapping it to something not very useful just because it changes in regional keyboard layouts is just lame solution.

Then what to do, make 5-6 hotkeys for same thing in different keyboards and some users that have various of this keys have the same function in the keyboard?

I would strongly recommend not using the ~ for mode transfer. That key is not directly available in many keyboard layouts and it will be mapped to a functionality that should always be directly exposed in order for some modes to be functional. As an example, 2 of 4 keyboards I'm using in my computers don't have that key.

This is artificially constructed problem. Blender easily allows to map same operator to multiple different keys, so there's nothing preventing the keymap to have the tilde key operator mapped multiple times also for the keys in place of tilde in other regional keyboard layouts. Also, you are just offloading that problem to a less used feature, but it will still be there when one tries to use that less used feature, it won't go away. But a key that's directly under escape is a very valuable key reach-wise, so mapping it to something not very useful just because it changes in regional keyboard layouts is just lame solution.

Then what to do, make 5-6 hotkeys for same thing in different keyboards and some users that have various of this keys have the same function in the keyboard?

Yes, exactly. In almost all the cases, the tilde key on the other regional keyboards uses some really obscure symbol that's not mapped on any easily accessible key on the US layout. In fact that's the reason they usually sacrifice the tilde key for it. If it was easily accessible somewhere else on the keyboard, then there would not be a need to sacrifice one keyboard key. So having additional mapping of the same function for those obscure regional symbols in place of the tilde key will hardly create any conflict somewhere else on the keyboard.

If you disagree, then please post a very specific instance where a conflict would occur. Post an example of a specific regional keyboard layout, which would create a conflict (or a duplicate binding) in its layout, or in any other of the regional layouts, if its symbol which is in place of tilde key was mapped. You will realize how difficult it is to actually make a problem out of it :)

I think it's okay, not a big deal, having switch operator for different modes is what is important, imo. New users will use default hotkey setup, as tilde is not mapped in default hotkeys. More experienced users will remap it, I remap most of default hotkeys anyway, most important thing is for this functionality to be integrated in next builds, even if it won't be mapped to anything, it's okay as a hidden operator. No reason to blow this out of proportion, people will always have different needs, personal habits, different views on hotkey mapping.

I think it's okay, not a big deal, having switch operator for different modes is what is important, imo. New users will use default hotkey setup, as tilde is not mapped in default hotkeys. More experienced users will remap it, I remap most of default hotkeys anyway, most important thing is for this functionality to be integrated in next builds, even if it won't be mapped to anything, it's okay as a hidden operator. No reason to blow this out of proportion, people will always have different needs, personal habits, different views on hotkey mapping.

This is not completely true.

First of all, the ability of customization is no excuse for the defaults not being the best they can possibly be.

Second of all, Blender is an extreme outlier in terms of how good (bad in this case) the default keymap is. People have different needs, personal habits, different views on hotkey mapping especially in the land of Blender because of just how weird the default state of it is. I have used many other pieces of software in my life, and I am sure you have too, yet I never felt such a strong need to "fix something" in terms of keymap that I feel in Blender. Take Photoshop for example. People rarely feel the need to completely overhaul the keymap before they can even start using it. Where as in Blender, it's rather common occurrence. Software should not require you to invest several days of work into customizing and refining your own configuration before it starts being at least remotely productive.

I don't know how many problems will have between hundreds of different keyboard distribution. But only between UK and Spanish latinamerica you have one, for example. Don't have sense have 10-20-40 keys mapped for each distribution in the world.

I don't know how many problems will have between hundreds of different keyboard distribution. But only between UK and Spanish latinamerica you have one, for example. Don't have sense have 10-20-40 keys mapped for each distribution in the world.

No, there is not that many... There's just about a dozen of the major ones. Anyway, even people using those regional keyboards will most likely switch to US keyboard mode when using Blender if they are serious about using Blender, because otherwise those regional layout change way more keys than just tilde, so even current default Blender keymap breaks on many more places. Bottom line is that not using tilde key for something very useful given how lucrative key it is just because of regional keyboard variations is a poor argument.

This is not true. I have never changed a keyboard layout to use a program and I don't know nobody that do this. It is not even installed as default in windows.

I don't think anyone expects thousands, even millions of people, to change a keyboard layout for a hotkey that makes it unfeasible for them to type in their language.

I think it's okay, not a big deal, having switch operator for different modes is what is important, imo. New users will use default hotkey setup, as tilde is not mapped in default hotkeys. More experienced users will remap it, I remap most of default hotkeys anyway, most important thing is for this functionality to be integrated in next builds, even if it won't be mapped to anything, it's okay as a hidden operator. No reason to blow this out of proportion, people will always have different needs, personal habits, different views on hotkey mapping.

This is not completely true.

First of all, the ability of customization is no excuse for the defaults not being the best they can possibly be.

Second of all, Blender is an extreme outlier in terms of how good (bad in this case) the default keymap is. People have different needs, personal habits, different views on hotkey mapping especially in the land of Blender because of just how weird the default state of it is. I have used many other pieces of software in my life, and I am sure you have too, yet I never felt such a strong need to "fix something" in terms of keymap that I feel in Blender. Take Photoshop for example. People rarely feel the need to completely overhaul the keymap before they can even start using it. Where as in Blender, it's rather common occurrence. Software should not require you to invest several days of work into customizing and refining your own configuration before it starts being at least remotely productive.

I understand your sentiment completely and in no way I oppose you. The main concern for me is that Switch operator in different modes would be integrated in the next build and won't be postponed for another year or indefinitely, like it happened with switch object in sculpt mode last time, when devs couldn't decide where to bind it in default hotkeys. If nobody likes the proposed hotkeys by developers, fine, add this operator as the one with no key-map, so that experienced users could map it any way they want. In my opinion that is the most rational approach.

And regarding hotkeys, there are no perfect "industry standard" hotkeys, I change all default hotkey for all applications and DCCs I use, and I'm not the only one who tries to have maximum ergonomics because they work 12 hours a day using different DCCs. Claim that hotkeys in "industry standard" software is simple and work out of the box and universally acceptable is not correct. Many "industry standard" software packages from "you know which company" don't have proper hotkey customization capabilities, they're not even close to what Blender can do. Many keys in Autodeath products are completely hard-coded and you can't even rebind them, a lot of peripheral hardware is not being identified by this junk of software, I can go on and talk about disabilities in every "industry standard" software, when it comes for hotkeys for hours, that doesn't change anything. Every software is different and the workflow philosophy is different, that is why you literally can't unify it all and can't please every user.

Like I said, imo, new users won't even notice that tilda key is occupied with this operator now, as they are just starting out and it will take them a while to start customizing their hotkeys. As for experienced users, I really don't think it will destroy their keymaps, if they don't like they can literally spend less than 1 minute to rebind it.

If you feel like the Blender default keymaping is an outlier in terms of default keymapping, then what is your suggestion exactly? I propose, for developers if they can't decide which hotkey to bind this operator to, DO NOT postpone it. Include it in the build as an unmapped operator, so that "conservatives" complaining about every minuscule change in UI/Hotkeys will be delighted, and "extremists" that don't use default hotkeys and have their own ergonomic setups can be pleased, that's all. I literally don't care about defaults as long as there is an option to customize, as long as nothing is hardcoded like in some "industry standard" software, but what I am concerned about is new functionality being postponed for a very long time.

Why not duplicate “Industry Compatible” keymap behavior?

Here is a problem, industry standards do not cover industry requirements for a long time.

Industry Compatible layout it is already available anyway.
Also this proposed layout is optional as well, so why not.

I am an old user of Blender. To be honest, every time I update Blender, the first thing I do is spend ten minutes modifying the shortcut keys. Because many 2.7 shortcut keys have been removed in 2.8. I personally hope that if there is a preset that can keep the existing shortcut keys of 2.8x and include the shortcut keys of 2.7x, it will be more convenient.

Industry standard shortcut keys, I didn’t think they would be very useful for beginer. max ≠ maya ≠ Houdini ≠ C4d, who is the industry standard? Perhaps the 2.7 preset is better, including 3ds max shortcut presets, maya shortcut presets, and so on. Similarly, the new toolbar, I almost never click.

By the way, I really want to know when I can add shortcut keys to the enumeration menu(https://developer.blender.org/T65704), I need it very much, as a non-program user, setting some shortcut keys is still difficult for me

If you feel like the Blender default keymaping is an outlier in terms of default keymapping, then what is your suggestion exactly? I propose, for developers if they can't decide which hotkey to bind this operator to, DO NOT postpone it. Include it in the build as an unmapped operator, so that "conservatives" complaining about every minuscule change in UI/Hotkeys will be delighted, and "extremists" that don't use default hotkeys and have their own ergonomic setups can be pleased, that's all. I literally don't care about defaults as long as there is an option to customize, as long as nothing is hardcoded like in some "industry standard" software, but what I am concerned about is new functionality being postponed for a very long time.

This is my suggestion exactly: https://blenderartists.org/t/a-proper-keymap-for-blender-2-9/1145406

I even offered to make version of it to be distributed with Blender, but was shut down because the person in charge disagreed, and wanted to make a weird mashup of all different keymaps other industry 3D packages have. That person completely rejected any notion of consistency, and simply thought that averaging keymaps of all the other 3D apps out there into one would be a solution. That's why we ended up with almost universally hated "Industry Compatible" keymap almost no one actually considers industry compatible. The one I made, on the other hand, people actually seem to like and enjoy using.

Considering topic.
To understand how effective a system is we can estimate its efficiency in comparison with current solution.
To emulate such a behavior you need to click a mode menu, which shows your current context, and press a corresponding number.

So, technically, a proposed system saves a menu click.
Sometimes saving a menu click is a big deal - that depends on relevancy value. But it is hard to be sure that this is such a case, since menu provide visual information about available modes in context of your current selection.

Why is this moved to to bcon2 features when even according to the user to the tokens awarded to this task, the majority of people are against it?

I am not sure this dictatorship approach is appropriate for a community centric and community funded project. You can't just force users to like your decision.

I think this is a lot of work for little benefit. It's already easy to switch between edit and object mode with tab, as for sculpt and texture paint modes, people should be used to switching workspace instead, as for the other modes, I honestly don't see people memorizing a number just for them. But what really makes this a waste of time in my opinion because it is so much easier to switch modes with the ctrl+tab pie menu. Using the pie menu you don't have to memorize anything, with just one shortcut you can quickly change to any mode, and if you want to use number to switch modes, you can simply open the pie menu and press the number... If the goal is making switching to any mode easier, there already is an option to switch the pie menu to tab instead of ctrl+tab.

To me the biggest issue is that the current proposal would make it impossible to quickly toggle collections in object mode... This by itself makes it not worth it. Why remove a feature to add a redundant feature, while also making changing submodes more cumbersome? People are so used to 1/2/3 for vertex/edge/face, even people that want number to change modes want it that way. How can a bunch of keys and pie menus be any easier than a single pie menu that's already implemented?

silex (silex) added a subscriber: silex (silex).EditedJun 4 2021, 5:34 PM

If users are about to re-learn their muscle memory again why not ship Blender with 'Tab for pie menu' option enabled by default? 'Tab' pie-menu is way faster than finding Weight Paint at '6' on the keyboard.
As soon this is rolled out I'm changing 1-2-3 shortcuts back to vertex-edge-face.

If users are about to re-learn their muscle memory again why not ship Blender with 'Tab for pie menu' option enabled by default? 'Tab' pie-menu is way faster than finding Weight Paint at '6' on the keyboard.

Do you mean enable Tab for pie menu and pie menu on drag options to delimit single press and pressholding tab button between object-edit modes and modes pie menu actions?
This is a way to quickly switch modes, which has already been solved in Blender before this proposal, without losing fast switching object-edit modes.

Exactly.

Well, when I think about this proposed layout I think about it as an attempt to bring a layout option with a property of a General Consistensy, and it is impossible not to appreciate it.

During 2.8 redesign there was a conflict brought between

  • non-multiref 3dsmax solution (1 2 3 for submodes in edit mode)
  • and multiref Blender solution (numbers for collections in object mode)

as a result the same keys are occupied with different functionality in different modes which is confusing.

People are so used to 1/2/3 for vertex/edge/face, even people that want number to change modes want it that way.

When we tried to slove such a confusion when was switching from 3dsmax to Blender a long time ago, we found solution with tilda, which cannot be used in default layout anyway.
So the problem was that it is too easy to get used to such a layout, and such an inconsistency cannot be easily solved, because it satisfies object mode and edit mode demands separately without reconciling them.
We tried to warn about such a design issue asap though, based on our experience, but it was too late.

Changing view layers is the only viable way to replace the old layers system. We only need quick shortcuts for each layer view. Sadly it's not possible to add shortcuts. Imagine pressing 4 will give you the default layer view, press 5 and you go to the next layer, hide any objects you like and then simply going back and forth between them would be fast. If you want to copy one layer view into another slot you could hold a modifier key and then the desired slot or key.

Changing view layers is the only viable way to replace the old layers system.

Such a possibility was taken into account - the problem is that such a behavior is not flexible enough to solve a combinatorics task solved by QCD/layers.
For example, you have 2 collection with 2 contexts, such as retopo mesh and basemesh, for example, named A and B.
The number of possible combinations is 2^n-1 = 2^2-1 = 4-1 = 3 (they are only A, only B, both AB, and you need all of them)

But when you have 5 collections there are 2^5-1 = 32-1 = 31
So you need 31 combination, view layers, or frames (for example, maya users use visibility animation, so each frame take a combination) to satisfy only 5 collections combinations.

QCD/Layers have 20 slots, so there are 2^20 -1 = 1048575 possible quick access combinations powered with hiding and isolation possibilities.

Also, view layer switching is not a self-representative easy discoverable solution, you have to know about VLs in order to use them.
It also dont solve a shortcut inconsistency problem.

You can have more than 20 View Layers...., each with a descriptive name.... But I agree View Layers are no discoverable, which is why I said they need more attention.

You can have more than 20 View Layers...., each with a descriptive name.... But I agree View Layers are no discoverable, which is why I said they need more attention.

15 View layers can store 4 objects combinations, so they have capacity of 4 QCD/Layer slots and requires proper setup every time they are used - it is possible to send an object to a collection to filter it out, but it is impossible to send it to a View Layer.

I really appreciate that the keymap is being rethought,

but I have to say I feel this can be a bit of a waste of hotkeys in many modes: why? because you don't change modes as often as you change tools in each mode.
Normally you go to a mode, work there with multiple tools in said mode.

So I propose to use the numbers from 1 to 0 and map them to the tools (from the left panel) on like select, 3d cursor, move, rotate, scale, (from the tool panel which are consistent in almost every mode aside from sculpting) and the ones that come after the first 5 would be replaced with the next in the list.

Note that I did it in my case with the numpad keys but with "emulate numpad on" because it brings other keys I use often to this side of the keyboard. but I'm using the numbers from the top of the keyboard.

Now the only mode that would require extra work is sculpt as it has so many tools, to witch I'd do shift 1-0 to add more tools and if needed Alt 1-0 for more if needed, its just that sculpt is a bit over bloated with tools to the point we could fill up an entire keyboard with just its tools.
But maybe that mode could be treated differently too.

Its an Idea and as I said I've been testing it personally for months and makes sense because its easy to remember the keys that are inherent to the modes you use often and its also easy to infere what the keys do in the modes you dont use that often.

Just my 2 cents.

I really appreciate that the keymap is being rethought,

but I have to say I feel this can be a bit of a waste of hotkeys in many modes: why? because you don't change modes as often as you change tools in each mode.
Normally you go to a mode, work there with multiple tools in said mode.

So I propose to use the numbers from 1 to 0 and map them to the tools (from the left panel) on like select, 3d cursor, move, rotate, scale, (from the tool panel which are consistent in almost every mode aside from sculpting) and the ones that come after the first 5 would be replaced with the next in the list.

Note that I did it in my case with the numpad keys but with "emulate numpad on" because it brings other keys I use often to this side of the keyboard. but I'm using the numbers from the top of the keyboard.

Now the only mode that would require extra work is sculpt as it has so many tools, to witch I'd do shift 1-0 to add more tools and if needed Alt 1-0 for more if needed, its just that sculpt is a bit over bloated with tools to the point we could fill up an entire keyboard with just its tools.
But maybe that mode could be treated differently too.

Its an Idea and as I said I've been testing it personally for months and makes sense because its easy to remember the keys that are inherent to the modes you use often and its also easy to infere what the keys do in the modes you dont use that often.

Just my 2 cents.

Interesting, this is pretty much how currently I keybind my sculpt, weight-paint, armature edit/pose modes and particle modes as of now, I don't use gizmos though (edit mode is completely different). I don't mind having switch object dedicated shortcut, I would use it quite often, currently I use switch object operator in sculpt mode all the time, pretty sure it will be handy in other modes too, I think it depends on the mode though and how coherently it is implemented.

I really like that idea - it seems consistent and easy to remember - because you have a visual cue on the left!

I agree with luciano also because tab for pie menu should be default, and is the fastest way to change once you get used to it this just seems not good enough

numbers for tools!

Numbers for collections still faster & useful to switch between them the only exception is in edit mode..etc where it's not needed most of the time.
so I think accept the inconsistency of this and probably the best solution imo is to add another pie menu with a hotkey that's shared with the submodes .

You will always make mistakes using such a system, usually Blender does not include such things in itself.
This type of a shortcut inconsistency, when you use same keys for different functions in different modes, generates a "cursed loop" (it is useful - it is inconsistent - but it is so useful - but it is so inconsistent), which you cannot exit it without a sacrifice.

There was 4 options available:

  • use blender solution (slow ctrl+tab, but multiref compatible)
  • use max solution (instant edit mode, fast submodes switching but loose multiref)
  • keep both (keep inconsistency)
  • keep none (loose both fast submodes and multiref for the sake of consistency, an actual proposal)

When we tried to solve such an issue back in 2012 when we was switching to Blender, we decided to sacrifice a bit of speed with tilda solution, and test it on pretty hard organic modeling workflow, when you have to switch between submodes a lot.
Such a solution passed the test, but tilda is not available on some keyboards, so is not accessible for defaults.
Also, with current design collection switching is not that useful, since disallow to control collection combinations visually, and also relies on chaining-dependent RTO (Visibility RTO), so multiref was generally heavily damaged.

I think it's a bad idea to have multiple ways of doing the same thing (in relation to keyboard shortcuts that is). It eats away at valuable keys that could otherwise be used for something not already assigned to a shortcut.

In my opinion, it would be better to choose one method and stick with it, my preference would be the tab key to open a multilevel pie menu (similar to houdini's C menu). That way you can instigate everything from one key , instead of having to look at the keyboard, find the number you want, and then still end up having to navigate a pie menu anyway for certain numbers.

I agree with Michael Cambpell, thats why i added my proposal becuse in a world where yo have a nice pie menu (tab) to switch modes then numbers can consistently be the tools on the side.

Tab pie menu is so much better than this! No need to memorize a key for each mode. It's quick to use and leaves the number keys free for more useful things.

My first reaction was negative because I use 1 2 3 for mesh edit mode way more than switch to other nodes, but now after thinking about it consistency is probbaly worth it. I used a lot of methods for this over the years: vanilla 2.7x tab and ctrl+tab, wazou pie menus with direct access to submodes (probably my favorite method) and now vanilla 2.8x pies so I could live with another switch.

My only objection is that I could only reach to about 5 without moving left hand from "default" position (where majority of hotkeys are) and 6 7 8 are so far and require so much hand movement that this method is definitely going to be slower than 2.8x pie menu for armatures.

Just my 2 cents. When TAB pie menu is opened, we can see the actual mode's name in the pie, so we don't need to remember anything.
If hitting actual number key is needed, I will likeay hit several number keys to find the mode I want to switch. I sometimes do the same thing on maya, 4〜7 to change shading mode, F8〜F11 to change select mode. But in blender, switching mode takes some time so it can be more annoying to find the mode.

I have never changed a keyboard layout to use a program and I don't know nobody that do this.

Well, it is quite... deeper at corporate workflow design level.

There is always the only one way to work comfortably - the one to which the person is accustomed. Thus, the world is ruled by defaults.
But people are able to get used to literally anything, so there is a main problem of a general workflow design - which approach is worth getting used to.

To be able to analyse that question, corporate workflow designer have to compare existing solutions to different problems in different software.
So, to became a workflow designer you have to make it in a bruteforce way

  • Learn 3dsmax - get used to it.
  • Learn AutoCAD - get used to it
  • Learn Maya - get used to it.
  • Learn Blender - get used to it.
  • Learn Revit - get used to it.
  • Learn Sketchup - get used to it.
  • Learn Zbrush - get used to it...

and so one, for a wide range workflows in order to be able to compare software capabilities, format conversion abilities and approaches.
A workflow designer have to clearly know the difference between Autocad/Revit/3dsmax/Sketchup groups (common groups system), Maya groups (parenting system) and Blender groups (tagging system) to have a common language with specialists.
For example, I don't know Maya deep enough, so I hired maya addon developer and turned him into Blender addon developer, for the ability to compare software even by API to fill the gap.

It is a hard way, but it is the only way to design sustainable workflows at the corporate level.