Cluttering Tools with keymap exceptions needs to stop!

I have just spent half an hour figuring out why keymap entries defined for one specific tool are affecting other 3D view tools despite being defined only for that particular one. This was the culprit:

Who in their right mind thought it would be a good idea to clutter tools outside of the user preferences window with hardcoded keymap exceptions? Blender’s keymap system is such a mess it’s becoming literally impossible to manage, and throwing another layers of exceptions on top of that is just completely insane.

Right now, we have the messy, complicated keymap.

On top of that, we have hard coded set of keymap behavior switches for Blender’s keymap:

And now newly as a third layer, we have yet another switch of this kind right in the UI outside of the preferences:
image

You can not just randomly start throwing things that affect/override keymap behavior around the UI. It does not belong there. It’s not something users will ever want to change on the fly. It’s the kind of workflow preference that’s set up once and then forgotten about. If anything, put it in the Blender’s keymap preferences, where the things like Spacebar Action, or Activate Gizmo Press vs Drag are:


We really can’t have 3 separate places the keymap behavior is affected from. This is really becoming unmanageable.

This is really crazy. The preferences are being just randomly thrown around the user interface without any thought of where they actually belong.
:confounded:

Keymap definition needs to be sacred. If I want my keymap to box select on drag for the move tool, then I will set it up so. This sets up a scary precedent of uncertainty, where if you define your keymap functionality correctly, you are still not sure it will work correctly because there may be random switches/override hidden away somewhere in UI which modify the behavior without your knowledge.

1 Like

I find this design decision to be particularly frustrating, as it seems to sacrifice clarity for the sake of using the tool system. What happens on click-drag could be handled by a operator (which would really just be a wrapper for the existing selection operators), leaving the tool keymaps to work like actual keymaps.