Keymap: use number keys for mode switching (2nd Iteration) #88071

Open
opened 2021-05-06 06:19:27 +02:00 by Campbell Barton · 93 comments

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:
{F10130043, size=full}

  • 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 #84380 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 @pablovazquez based on notes from the UI meeting on 20 May.

## 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: {[F10130043](https://archive.blender.org/developer/F10130043/image.png), size=full} * 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 #84380 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 @pablovazquez based on notes from the UI meeting on 20 May.*
Author
Owner

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Author
Owner
Added subscribers: @ideasman42, @baoyu, @system-system, @jta, @Maged_Afra, @AndresStephens, @finirpar, @AlbertoVelazquez, @Gilberto.R, @1D_Inc, @xan2622, @TheRedWaxPolice, @RedMser, @JulianEisel

So are we going to kill multiref modeling in Blender completely, keeping shortcuts inconsitency between edit mode and object mode, where the same keys acts differently?
Mode switching is not even used that often, and it was never a problem, it have low relevancy ratio to occupy such a well located hotkeys.
This is one of the possible solutions, not the best one.

So are we going to kill multiref modeling in Blender completely, keeping shortcuts inconsitency between edit mode and object mode, where the same keys acts differently? Mode switching is not even used that often, and it was never a problem, it have low relevancy ratio to occupy such a well located hotkeys. This is one of the possible solutions, not the best one.
Author
Owner

In #88071#1156675, @1D_Inc wrote:
So are we going to kill multiref modeling in Blender completely, keeping shortcuts inconsitency between edit mode and object mode, where the same keys acts differently?
Mode switching is not even used that often, it have low relevancy ratio to occupy such a well located hotkeys.
This is possible solution, not the best one.

Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I had impression that collections didn't map so usefully to numbers, making this feature less useful/popular.

If feedback shows this isn't the case, this proposal can be closed/rejected based on this.

> In #88071#1156675, @1D_Inc wrote: > So are we going to kill multiref modeling in Blender completely, keeping shortcuts inconsitency between edit mode and object mode, where the same keys acts differently? > Mode switching is not even used that often, it have low relevancy ratio to occupy such a well located hotkeys. > This is possible solution, not the best one. Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I had impression that collections didn't map so usefully to numbers, making this feature less useful/popular. If feedback shows this isn't the case, this proposal can be closed/rejected based on this.

Let's analyse those layouts from workflow point of view.

  • Dominant edit/object mode switching on tab and quick access slots (aka layers) is preferable for most linear modeling, including massive Architectural/CAD, which imply complex structures modeling, such as multiref modeling (CADwork)
  • The proposed multimodes switching is useful mostly for complete asset modeling, such as gamedev modeling, characters and animation (ARTwork)
    We perform gamedev modeling as well, so basic motivation of this proposal is understandable to us.

In #88071#1156683, @ideasman42 wrote:
Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I had impression that collections didn't map so usefully to numbers, making this feature less useful/popular.

Yes, loosing quick access slots paradigm was quite fatal to us, as an architectural company, since Blender was the only software at industry level where multiref modeling was succesfully solved.
As a result of the hasty design change, the ability to perform multiref modeling was not taken into account. Indeed, after the redesign, it is difficult to come up with a design solution that could elegantly solve multiref problem by default.
However, we tried to rebuild this functionality as part of built-in Collection Manager addon to provide working mapping solution to systems with different capacities.

But since the default behavior is not multiref-compatible, with time we will loose the ability to hire modellers fluent in multiref modeling on a market.
This will crush us.

Let's analyse those layouts from workflow point of view. - Dominant edit/object mode switching on tab and quick access slots (aka layers) is preferable for most linear modeling, including massive Architectural/CAD, which imply complex structures modeling, such as multiref modeling (CADwork) - The proposed multimodes switching is useful mostly for complete asset modeling, such as gamedev modeling, characters and animation (ARTwork) We perform gamedev modeling as well, so basic motivation of this proposal is understandable to us. > In #88071#1156683, @ideasman42 wrote: > Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I had impression that collections didn't map so usefully to numbers, making this feature less useful/popular. Yes, loosing quick access slots paradigm was quite fatal to us, as an architectural company, since Blender was the only software at industry level where multiref modeling was succesfully solved. As a result of the hasty design change, the ability to perform multiref modeling was not taken into account. Indeed, after the redesign, it is difficult to come up with a design solution that could elegantly solve multiref problem by default. However, we tried to rebuild this functionality as part of built-in [Collection Manager ](https://youtu.be/yiti0xWO7Wg?t=771) addon to provide working mapping solution to systems with different capacities. But since the default behavior is not multiref-compatible, with time we will loose the ability to hire modellers fluent in multiref modeling on a market. This will crush us.

The feedback is obvious, the current implementation makes it unfeasible to use this feature.

But I am going to ask again, please, to change the implementation to bring back to life this tool. Just don't map the collections, hide or show the collections according to the color they have in the outliner. It is simple to implement, completely changes the behavior and makes usable this tool that is so much missed.

imagen.png
and the zero to show all collections.

And the basic idea is easy to implement

      vlayer = bpy.context.view_layer
      for col in vlayer.layer_collection.children:
          color = bpy.data.collections[col.name].color_tag
          if color == 'COLOR_01':
              col.exclude = False
          else:
              col.exclude = True
      return {'FINISHED'}

Regarding changing modes with the keys, I've been working in video games for fifteen years and I don't see any way to make it interesting. It is a function that is rarely used, the only one that is really used is to enter edit mode as to compensate for a hotkey. But when you are animating you are animating, when you are painting vertices you are painting them,... but you are not constantly changing modes every 20sec as it does happen with show and hide collections while you are modeling.

The feedback is obvious, the current implementation makes it unfeasible to use this feature. But I am going to ask again, please, to change the implementation to bring back to life this tool. Just don't map the collections, hide or show the collections according to the color they have in the outliner. It is simple to implement, completely changes the behavior and makes usable this tool that is so much missed. ![imagen.png](https://archive.blender.org/developer/F10055984/imagen.png) and the zero to show all collections. And the basic idea is easy to implement ``` vlayer = bpy.context.view_layer ``` ``` for col in vlayer.layer_collection.children: color = bpy.data.collections[col.name].color_tag if color == 'COLOR_01': col.exclude = False else: col.exclude = True return {'FINISHED'} ``` Regarding changing modes with the keys, I've been working in video games for fifteen years and I don't see any way to make it interesting. It is a function that is rarely used, the only one that is really used is to enter edit mode as to compensate for a hotkey. But when you are animating you are animating, when you are painting vertices you are painting them,... but you are not constantly changing modes every 20sec as it does happen with show and hide collections while you are modeling.
Contributor

Why replace a useful feature with a reduntant way to change modes? I don't see having a number for each mode as being easier than looking up a pie menu, as it would require more memorization.

Why replace a useful feature with a reduntant way to change modes? I don't see having a number for each mode as being easier than looking up a pie menu, as it would require more memorization.

»! In #88071#1156683, @ideasman42 wrote:

Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion.

I think this happened due to a common misconception.
Layers have never been a scene customization tool as they are obviously quite limited for this purpose.
It always was a powerful modeling tool because of fast access feature, that was somehow used as a scene setup tool because of no other option left. There were no proper scene customization tool before Collections in Blender.

Blender was changed, but the modeling requirements remain the same - fast access is still needed for modeling.

»! In #88071#1156683, @ideasman42 wrote: > Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I think this happened due to a common misconception. Layers have never been a scene customization tool as they are obviously quite limited for this purpose. It always was a powerful modeling tool because of fast access feature, that was somehow used as a scene setup tool because of no other option left. There were no proper scene customization tool before Collections in Blender. Blender was changed, but the modeling requirements remain the same - fast access is still needed for modeling.
Member

Added subscriber: @JulienKaspar

Added subscriber: @JulienKaspar
Member

Just to leave my opinion on the topic as well:
IMO there is no implementation for mode switching that is more convenient than the current pie menu. It's consistent, easy to memorise and only uses one shortcut.
The mentioned open topics in this task also expose the big downsides to using the number keys for mode switching. There are just not enough number keys for all modes and sub modes and past number 5 I would say it is no longer convenient to use.
It would also mean that sub modes will become a menu popup again (or even a pie menu) on Ctrl + Tab.

Loosing the functionality of quickly hiding, unhiding collections is also not worth it. This is still a great feature that is adding convenience to multiple workflows and tasks, whereas replacing it with mode switching via number keys is not adding any convenience in switching modes that we don't already have.

Even if some users insist in using these shortcuts for mode switching, then it can be made an option (Or they can edit the keymap themselves. There should be no problem with that).
But I would not make this behaviour the default.

Just to leave my opinion on the topic as well: IMO there is no implementation for mode switching that is more convenient than the current pie menu. It's consistent, easy to memorise and only uses one shortcut. The mentioned open topics in this task also expose the big downsides to using the number keys for mode switching. There are just not enough number keys for all modes and sub modes and past number 5 I would say it is no longer convenient to use. It would also mean that sub modes will become a menu popup again (or even a pie menu) on Ctrl + Tab. Loosing the functionality of quickly hiding, unhiding collections is also not worth it. This is still a great feature that is adding convenience to multiple workflows and tasks, whereas replacing it with mode switching via number keys is not adding any convenience in switching modes that we don't already have. Even if some users insist in using these shortcuts for mode switching, then it can be made an option (Or they can edit the keymap themselves. There should be no problem with that). But I would not make this behaviour the default.
Author
Owner

In #88071#1156687, @AlbertoVelazquez wrote:
The feedback is obvious, the current implementation makes it unfeasible to use this feature.

But I am going to ask again, please, to change the implementation to bring back to life this tool. Just don't map the collections, hide or show the collections according to the color they have in the outliner. It is simple to implement, completely changes the behavior and makes usable this tool that is so much missed.

imagen.png
and the zero to show all collections.

And the basic idea is easy to implement

@JulienKaspar thanks for the feedback.

As an alternative to the current layer switching method, what do you think of this suggestion?

> In #88071#1156687, @AlbertoVelazquez wrote: > The feedback is obvious, the current implementation makes it unfeasible to use this feature. > > But I am going to ask again, please, to change the implementation to bring back to life this tool. Just don't map the collections, hide or show the collections according to the color they have in the outliner. It is simple to implement, completely changes the behavior and makes usable this tool that is so much missed. > > ![imagen.png](https://archive.blender.org/developer/F10055984/imagen.png) > and the zero to show all collections. > > And the basic idea is easy to implement @JulienKaspar thanks for the feedback. As an alternative to the current layer switching method, what do you think of this suggestion?

In #88071#1157371, @finirpar wrote:
... but the modeling requirements remain the same - fast access is still needed for modeling.

Quite right, the presence of slots is associated with an increasing modeling complexity curve.

  • at the basic modeling complexity basic tools are used, so you can afford whatever setup, like switching mesh sub-entities or modes on numbers.
  • then hiding is used
  • then hiding is used with with local view isolation
  • then used all above and manual collections switching in the outliner (or industry standard analogues like common layers in any other software)
  • but when the modelling complexity reaches the top and when collection switching becomes enormous and overwhelming - you go to the quick access slots and their combinations for realtime visibility control of all those references, drawings, image planes, model parts, basemeshes and so on - to satisfy multireference (multiref) modeling requirements.

This was the only approach passed all our tests, that's why, for example, we switched from 3dsmax with its handy 123 for vertices/edges/faces, instant edit mode and unlimited layers to Blender - to expand our range of modeling workflows to the top complexity.
All this time while other software was cloning each other since 3dsmax 5, Blender has provided working solutions for common industry workflow issues.
As a result we actually thought, that it was a goal of Blender - to propose a unified workflow approach that fits everything (especially if to take into account that it is a program that combines sculpting and videoediting abilities at the same time).
It is quite unbelievable to us that the solutions to the problems we have investigated for such a long time was reached at no scope.

In #88071#1157436, @JulienKaspar wrote:
It would also mean that sub modes will become...

Well, here is one of the heaviest workflow design problems - a learning curve.
A questions like how to design or get used to a professional tool or approach that will save your life and mind from the extreme work during massive production if you never need so much in the very beginning.
What solution is worth learning and getting used to.
Such decisions are always a heavy tradeoff, since in the begining you always want to learn simple things.

Since Blender defaults was multiref-compatible, blender users got nice skills for a wide-range modeling workflows, as well as the ability to handle top modeling complexity.
As a result, using the same basic tools like extrude or bevel, but different interaction approach than in other software, Blender grow a generation of a well-trained speedmodellers.

> In #88071#1157371, @finirpar wrote: > ... but the modeling requirements remain the same - fast access is still needed for modeling. Quite right, the presence of slots is associated with an increasing modeling complexity curve. - at the basic modeling complexity basic tools are used, so you can afford whatever setup, like switching mesh sub-entities or modes on numbers. - then hiding is used - then hiding is used with with local view isolation - then used all above and manual collections switching in the outliner (or industry standard analogues like common layers in any other software) - but when the modelling complexity reaches the top and when collection switching becomes enormous and overwhelming - you go to the quick access slots and their combinations for realtime visibility control of all those references, drawings, image planes, model parts, basemeshes and so on - to satisfy multireference (multiref) modeling requirements. This was the only approach passed all our tests, that's why, for example, we switched from 3dsmax with its handy 123 for vertices/edges/faces, instant edit mode and unlimited layers to Blender - to expand our range of modeling workflows to the top complexity. All this time while other software was [cloning each other ](https://developer.blender.org/T54963) since 3dsmax 5, Blender has provided working solutions for common industry workflow issues. As a result we actually thought, that it was a goal of Blender - to propose a unified workflow approach that fits everything (especially if to take into account that it is a program that combines sculpting and videoediting abilities at the same time). It is quite unbelievable to us that the solutions to the problems we have investigated for such a long time was reached at no scope. > In #88071#1157436, @JulienKaspar wrote: > It would also mean that sub modes will become... Well, here is one of the heaviest workflow design problems - a learning curve. A questions like how to design or get used to a professional tool or approach that will save your life and mind from the extreme work during massive production if you never need so much in the very beginning. What solution is worth learning and getting used to. Such decisions are always a heavy tradeoff, since in the begining you always want to learn simple things. Since Blender defaults was multiref-compatible, blender users got nice skills for a wide-range modeling workflows, as well as the ability to handle top modeling complexity. As a result, using the same basic tools like extrude or bevel, but different interaction approach than in other software, Blender grow a generation of a well-trained speedmodellers.
Campbell Barton changed title from Use number keys for mode switching in the default keymap to Keymap: use number keys for mode switching 2021-05-07 15:06:33 +02:00
Member

@ideasman42 I think he proposal to tie the number keys to certain collection colors can be really good!
It just needs to be made obvious in the UI or tooltips that this is how it works. It can easily be a very hidden feature or many people will even think the collection switching shortcuts are gone, when in fact the functionality just has changed.
Adding a small number to the color icons in the right click menu might be a good indicator in additon to a tooltip explaining the shortcuts.

@ideasman42 I think he proposal to tie the number keys to certain collection colors can be really good! It just needs to be made obvious in the UI or tooltips that this is how it works. It can easily be a very hidden feature or many people will even think the collection switching shortcuts are gone, when in fact the functionality just has changed. Adding a small number to the color icons in the right click menu might be a good indicator in additon to a tooltip explaining the shortcuts.

In #88071#1156687, @AlbertoVelazquez wrote:

imagen.png

Interesting idea.
This can work with proper design.

> In #88071#1156687, @AlbertoVelazquez wrote: > ![imagen.png](https://archive.blender.org/developer/F10055984/imagen.png) Interesting idea. This can work with proper design.

Added subscriber: @Leroy-Xie

Added subscriber: @Leroy-Xie

I am very satisfied with the current settings( use {key 1}, {key 2}, {key 3}... to switch collection in object mode, I almost never change the color of the collection ), so I hope this will become an option if some change in future. In contrast, I care more about switching between other modes, such as switching between object nodes and world nodes in shader editor.

There are more and more types of node editors, but there are no quick shortcuts. Currently, you must use shift+F3 to loop switch. Maybe Compositor, Geometry Node Editror, and Shader Editor should be as sub-mode of Node Editor, so we can used {key 1}, {key 2}, {key 3}, {key 4} to quick switch nodes editor.

I am very satisfied with the current settings( use {key 1}, {key 2}, {key 3}... to switch collection in object mode, I almost never change the color of the collection ), so I hope this will become an option if some change in future. In contrast, I care more about switching between other modes, such as switching between object nodes and world nodes in shader editor. There are more and more types of node editors, but there are no quick shortcuts. Currently, you must use shift+F3 to loop switch. Maybe Compositor, Geometry Node Editror, and Shader Editor should be as sub-mode of Node Editor, so we can used {key 1}, {key 2}, {key 3}, {key 4} to quick switch nodes editor.

In #88071#1157436, @JulienKaspar wrote:

It would also mean that sub modes will become a menu popup again (or even a pie menu) on Ctrl + Tab.

Well, it is actually not that easy question.
Ctrl + Tab frees up the numeric keys, eliminating shortcuts inconsistency between modes, but it is longer to use.
123 for submodes is faster and more popular since it is an industry standard but eliminates consistency between modes and blocks the ability to reach top complexity modeling.

Personaly, I started working in CG from industry standard 123 for submodes approach (3dsmax) and retrained later to Blender approach for all kind of modeling including multiref, so I am familiar with using both layouts.

I think that switching to Ctrl+Tab will generate a lot of traffic, especially from industry standard users.
It is one of those solutions that is easy to bring but hard to take back, like syntactic sugar.
Thats why it is usually needed to be very accurate with industry standards implementations.

We use tilda key (~1 ~2 ~3) for switching submodes which as almost as fast as industry standards and frees up numeric keys as well, but tilda is not presented at some keyboards, so, unfortunately, this solution is not suitable for defaults.

> In #88071#1157436, @JulienKaspar wrote: > It would also mean that sub modes will become a menu popup again (or even a pie menu) on Ctrl + Tab. Well, it is actually not that easy question. Ctrl + Tab frees up the numeric keys, eliminating shortcuts inconsistency between modes, but it is longer to use. 123 for submodes is faster and more popular since it is an industry standard but eliminates consistency between modes and blocks the ability to reach top complexity modeling. Personaly, I started working in CG from industry standard 123 for submodes approach (3dsmax) and retrained later to Blender approach for all kind of modeling including multiref, so I am familiar with using both layouts. I think that switching to Ctrl+Tab will generate a lot of traffic, especially from industry standard users. It is one of those solutions that is easy to bring but hard to take back, like syntactic sugar. Thats why it is usually needed to be very accurate with industry standards implementations. We use tilda key (~1 ~2 ~3) for switching submodes which as almost as fast as industry standards and frees up numeric keys as well, but tilda is not presented at some keyboards, so, unfortunately, this solution is not suitable for defaults.
Member

Added subscriber: @Imaginer

Added subscriber: @Imaginer
Member

In #88071#1156683, @ideasman42 wrote:
Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I had impression that collections didn't map so usefully to numbers, making this feature less useful/popular.

If feedback shows this isn't the case, this proposal can be closed/rejected based on this.

Part of the Collection Manager addon's functionality is to restore the ability to easily switch between collections in a very similar manner to 2.7x, and solve the aforementioned problem. This is done by overriding the default collection switching hotkeys, and these are the only hotkeys that can conceivably be used for this purpose.
While changing the defaults will not directly affect the addon, it will indirectly cause problems because then the overrided hotkeys will be in direct conflict with the default keymap as opposed to simply replacing the defaults with an enhanced version of the same idea.

In #88071#1156687, @AlbertoVelazquez wrote:
The feedback is obvious, the current implementation makes it unfeasible to use this feature.

But I am going to ask again, please, to change the implementation to bring back to life this tool. Just don't map the collections, hide or show the collections according to the color they have in the outliner. It is simple to implement, completely changes the behavior and makes usable this tool that is so much missed.

imagen.png
and the zero to show all collections.

This is a very interesting idea and could be a very nice way to allow grouping collections. I think something like this could fit well in the Collection Manager addon, if you want to discuss this more, please come over to blender/blender-addons#69577 and we can chat.

> In #88071#1156683, @ideasman42 wrote: > Loosing the ability to easily switch layers from 2.7x was a significant down-side in my opinion. I had impression that collections didn't map so usefully to numbers, making this feature less useful/popular. > > If feedback shows this isn't the case, this proposal can be closed/rejected based on this. Part of the Collection Manager addon's functionality is to restore the ability to easily switch between collections in a very similar manner to 2.7x, and solve the aforementioned problem. This is done by overriding the default collection switching hotkeys, and these are the only hotkeys that can conceivably be used for this purpose. While changing the defaults will not directly affect the addon, it will indirectly cause problems because then the overrided hotkeys will be in direct conflict with the default keymap as opposed to simply replacing the defaults with an enhanced version of the same idea. > In #88071#1156687, @AlbertoVelazquez wrote: > The feedback is obvious, the current implementation makes it unfeasible to use this feature. > > But I am going to ask again, please, to change the implementation to bring back to life this tool. Just don't map the collections, hide or show the collections according to the color they have in the outliner. It is simple to implement, completely changes the behavior and makes usable this tool that is so much missed. > > ![imagen.png](https://archive.blender.org/developer/F10055984/imagen.png) > and the zero to show all collections. This is a very interesting idea and could be a very nice way to allow grouping collections. I think something like this could fit well in the Collection Manager addon, if you want to discuss this more, please come over to blender/blender-addons#69577 and we can chat.

Well, yes, as it was mentioned, we put a lot of efforts to provide a possible local solution to multiref modeling, but also mentioned another one - multiref compatibility of the defaults.

(If you remember, the same issue as with moving objects to collection mechanics, which had a nice solution in the CM addon, but also have to be solved by default and was discussed separately)

Well, yes, as it was mentioned, we put a lot of efforts to provide a possible local solution to multiref modeling, but also mentioned another one - multiref compatibility of the defaults. (If you remember, the same issue as with moving objects to collection mechanics, which had a nice solution in the CM addon, but also have to be solved by default and was discussed separately)

Hi @Imaginer

My problem with this addon is that it is more complex, much more, than my basic idea, which is very simple, just some hotkeys linked to some colors. While the addon, which I have tested in the past, is much more complicated to use, with different solutions for many levels of users.

Hi @Imaginer My problem with this addon is that it is more complex, much more, than my basic idea, which is very simple, just some hotkeys linked to some colors. While the addon, which I have tested in the past, is much more complicated to use, with different solutions for many levels of users.
Member

In #88071#1161358, @AlbertoVelazquez wrote:
Hi @Imaginer

My problem with this addon is that it is more complex, much more, than my basic idea, which is very simple, just some hotkeys linked to some colors. While the addon, which I have tested in the past, is much more complicated to use, with different solutions for many levels of users.

Ah, you're familiar with the addon, wonderful! While what may ultimately end up in the addon may be more complex, it allows for testing the design and finding any pitfalls that may crop up, and this could be useful for simpler versions as well. And who knows, the Collection Manager strives to make things as simple and easy as possible while also giving you as much power as possible, so the implementation may end up being on the simpler side, or it could be provided as a simpler default.

And if you have any feedback on improvements or ways to make things simpler about anything, please voice them in the task :)

> In #88071#1161358, @AlbertoVelazquez wrote: > Hi @Imaginer > > My problem with this addon is that it is more complex, much more, than my basic idea, which is very simple, just some hotkeys linked to some colors. While the addon, which I have tested in the past, is much more complicated to use, with different solutions for many levels of users. Ah, you're familiar with the addon, wonderful! While what may ultimately end up in the addon may be more complex, it allows for testing the design and finding any pitfalls that may crop up, and this could be useful for simpler versions as well. And who knows, the Collection Manager strives to make things as simple and easy as possible while also giving you as much power as possible, so the implementation may end up being on the simpler side, or it could be provided as a simpler default. And if you have any feedback on improvements or ways to make things simpler about anything, please voice them in the task :)
Member

Added subscriber: @pablovazquez

Added subscriber: @pablovazquez
Member

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
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 changed title from Keymap: use number keys for mode switching to Keymap: use number keys for mode switching (2nd Iteration) 2021-05-20 17:33:53 +02:00
Member

Added subscriber: @PabloDobarro

Added subscriber: @PabloDobarro
Member

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

In #88071#1163713, @Leroy-Xie wrote:
I really hope that this is just an optional setting,

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

> In #88071#1163713, @Leroy-Xie wrote: > I really hope that this is just an optional setting, Yes, it is designed as an optional setting ([D11188](https://archive.blender.org/developer/D11188))

In #88071#1163664, @PabloDobarro wrote:
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

> In #88071#1163664, @PabloDobarro wrote: > 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

In #88071#1164095, @1D_Inc wrote:
Yes, it is designed as an optional setting (D11188)

Thanks for your reply, I can sleep peacefully

> In #88071#1164095, @1D_Inc wrote: > Yes, it is designed as an optional setting ([D11188](https://archive.blender.org/developer/D11188)) Thanks for your reply, I can sleep peacefully
Member

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.

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.

Added subscriber: @Florian-10

Added subscriber: @Florian-10

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

In #88071#1164153, @Florian-10 wrote:
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.

In #88071#1164149, @JulianEisel wrote:
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...

In #88071#1164149, @JulianEisel wrote:
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.

image.png

  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.
> In #88071#1164153, @Florian-10 wrote: > 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. > In #88071#1164149, @JulianEisel wrote: > 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... > In #88071#1164149, @JulianEisel wrote: > 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. ![image.png](https://archive.blender.org/developer/F10134296/image.png) 2) 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.
Member

In #88071#1164162, @1D_Inc wrote:

  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.

> In #88071#1164162, @1D_Inc wrote: > 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.

In #88071#1164164, @JulianEisel wrote:
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.

> In #88071#1164164, @JulianEisel wrote: >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.
Author
Owner
- [D11188: Keymap: preference for using number buttons to switch modes](https://archive.blender.org/developer/D11188) has been updated to match the new design. - [D11189: Keymap: use D-Key for view-pie menu](https://archive.blender.org/developer/D11189) includes the change to the Tilda key mentioned in this design task.

In #88071#1163664, @PabloDobarro wrote:
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.

> In #88071#1163664, @PabloDobarro wrote: > 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.

Added subscriber: @MeshVoid

Added subscriber: @MeshVoid

This comment was removed by @MeshVoid

*This comment was removed by @MeshVoid*

Added subscriber: @APEC

Added subscriber: @APEC

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)

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

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
Contributor

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

In #88071#1163664, @PabloDobarro wrote:
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.

> In #88071#1163664, @PabloDobarro wrote: > 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'm really quite neutral on this. As longs as it can be remapped, it's okay =))

In #88071#1165493, @Rawalanche wrote:

In #88071#1163664, @PabloDobarro wrote:
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?

> In #88071#1165493, @Rawalanche wrote: >> In #88071#1163664, @PabloDobarro wrote: >> 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?
Contributor

In #88071#1165497, @AlbertoVelazquez wrote:

In #88071#1165493, @Rawalanche wrote:

In #88071#1163664, @PabloDobarro wrote:
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 :)

> In #88071#1165497, @AlbertoVelazquez wrote: >> In #88071#1165493, @Rawalanche wrote: >>> In #88071#1163664, @PabloDobarro wrote: >>> 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.
Contributor

In #88071#1165519, @MeshVoid wrote:
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.

> In #88071#1165519, @MeshVoid wrote: > 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.
Contributor

In #88071#1165568, @AlbertoVelazquez wrote:
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.

> In #88071#1165568, @AlbertoVelazquez wrote: > 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.

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.

In #88071#1165542, @Rawalanche wrote:

In #88071#1165519, @MeshVoid wrote:
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.

> In #88071#1165542, @Rawalanche wrote: >> In #88071#1165519, @MeshVoid wrote: >> 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.

In #88071#1165453, @APEC wrote:
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.

> In #88071#1165453, @APEC wrote: > 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

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
Contributor

In #88071#1165620, @MeshVoid wrote:
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.

> In #88071#1165620, @MeshVoid wrote: > 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.
image.png

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.

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

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.

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

This comment was removed by @Gilberto.R

*This comment was removed by @Gilberto.R*
Contributor

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?

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?

Added subscriber: @silex

Added subscriber: @silex

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. As soon this is rolled out I'm changing 1-2-3 shortcuts back to vertex-edge-face.

In #88071#1171107, @silex wrote:
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.
image.png

> In #88071#1171107, @silex wrote: > 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. ![image.png](https://archive.blender.org/developer/F10158205/image.png)

Exactly.

Exactly.
Member

Added subscriber: @PratikPB2123

Added subscriber: @PratikPB2123

In #88071#1171175, @silex wrote:
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.

In #88071#1170698, @Gilberto.R wrote:
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.

> In #88071#1171175, @silex wrote: > 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. > In #88071#1170698, @Gilberto.R wrote: > 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.

Added subscriber: @Xorrito

Added subscriber: @Xorrito

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

In #88071#1171333, @Xorrito wrote:
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.

> In #88071#1171333, @Xorrito wrote: > 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.

In #88071#1171385, @Xorrito wrote:
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.

> In #88071#1171385, @Xorrito wrote: > 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.

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

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.

demo.webm

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. [demo.webm](https://archive.blender.org/developer/F10175639/demo.webm) 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.

In #88071#1177814, @LucianoMunoz wrote:
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.

demo.webm

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.

> In #88071#1177814, @LucianoMunoz wrote: > 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. > > [demo.webm](https://archive.blender.org/developer/F10175639/demo.webm) > > 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.

Added subscriber: @JasonSchleifer

Added subscriber: @JasonSchleifer

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

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

Added subscriber: @AnityEx

Added subscriber: @AnityEx

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!

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!

Added subscriber: @CobraA

Added subscriber: @CobraA

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 .

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.

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 ](https://blendswap.com/blend/7579) 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.

Added subscriber: @3di

Added subscriber: @3di

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

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

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.

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.

Added subscriber: @Format64

Added subscriber: @Format64

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.

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.

Added subscriber: @chironamo

Added subscriber: @chironamo

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.

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.

Removed subscriber: @chironamo

Removed subscriber: @chironamo

In #88071#1165610, @AlbertoVelazquez wrote:
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.

> In #88071#1165610, @AlbertoVelazquez wrote: > 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.

Added subscriber: @AlexeyAdamitsky

Added subscriber: @AlexeyAdamitsky
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:23:29 +01:00
Pablo Vazquez added this to the User Interface project 2023-08-30 18:57:01 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
26 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#88071
No description provided.