Could basic details be added to this task, even if the design isn't yet done.

From the title, it's not obvious what this task refers to, it could mean anything from changes to GHOST's handling of non US keyboards to updates to the UI.

Will the hotkey system be merely getting a refactor/code cleanup? Or more like, an overhaul, including functionality? :)

It could really use the latter, imo, but I won't tire anyone with a long rant if the former is what this thread is for.

@Demeter Dzadik (Mets) while I'm didn't create this task, I listed known issues with the keymap system (things that as far as I know - maintainers of these areas would agree on).

If you have further suggestions, could you write them up?

Note that I'm not sure if there is time for larger refactor at the moment, it would just be interesting to know what issues you propose to solve with larger changes.

I do like to spend some considerable time tweaking keymaps.
The ability to reorder items will be a very welcome addition indeed and was high on my list. Picking from a list of available operators will also help.

UI wise, related to reordering one thing like to see the ability to add a new entries at any random point in the list, rather than just have am Add New button at the end. (Maybe through a button visible only on mouse hover?)

Ability to add new keys while in filtered view (by entering a search term at the top search box) is also very useful.
Given the complexity and extensive nature of the theymap one often has to do a search to find the correct context to enter a new keymap by checking where similar ones are placed.
Being able to enter one directly from search view will avoid a lot of blind searching and pinning down existing maps. Maybe the ability to duplicate an existing entry would also help.

The holy grail of keymap editing would be marking existing conflicts, but I suspect this is not trivial to do except for the most obvious of cases, given the complexity of possible combinations.

"Sticky headers" with always visible search box and import export buttons are probably a more generic improvement to the preferences window that would benefit other panes like addons, rather that a specific keymap improvement, and likely out of scope here. Sticky categories for the keymap tree would also help a user know where they currently are.

My dream shortcut editor would look something like this:

Avoiding duplicate shortcuts
Let shortcuts be assigned to multiple contexts. For example right now, the "Scale B-Bone" shortcut is duplicated in the "Pose" and "Armature" contexts. Instead, shortcuts would be able to have any number of contexts in which they are available, so we can have a single "Scale B-Bone" shortcut, and assign it to those two contexts.

Shortcut categories
I've been referring to these as contexts, I hope that's correct. I'm hoping it would be possible to organize the current contexts in blender into a sort of hierarchy - similar to how it is already done, just with a few changes. The goal would be that a single context has all of its potentially shortcut-conflicting contexts as a parent. For example:

• Window
  • 3D View
    • Pose
      • Weight Paint

This hierarchy implies that any shortcut that has Weight Paint as one of its contexts should be checked for conflicts against the Pose, 3D View and Window contexts. I don't know if there are any corner cases where this wouldn't work, but I can't think of any right now.

Shortcut Editor UI
The Shortcut Editor is a separate editor from the User Preferences. It can be opened from Edit->Shortcuts(or so)
It is split into three main columns:
On the left is a nested list of contexts, similar to what we have now, except they are selectable. By default, the root of this hierarchy is selected, which is the "Window" context. (Since I believe these shortcuts are available from anywhere in Blender)
In the center of the shortcut editor UI is a graphic of a keyboard layout. Perhaps there is a drop-down to choose other supported input devices, and perhaps the keyboard layout adjusts to non-english or non-standard layouts.
To the right of the input device graphic, is a list of shortcuts available in the selected context. This is where shortcuts can be filtered, modified, added and removed, ie. all the things we can do in today's Blender.

UX
Scenario: We want to add a new shortcut in Weight Paint and Mesh Edit modes to the Smooth Vertex Weight operator. "Smooth" starts with S, so that would be easy to remember, but we want to avoid conflicts of course.
We start by finding and selecting the Weight Paint context in the left side menu. We find it under Window->3D View->Pose->Weight Paint, and we select it. (Only one context can be selected at once.)
We notice that on the keyboard in the center, keys which have a shortcut assigned to them in this context(or any parent context) become highlighted in some color, and the shortcut list on the right side is updated with more shortcuts. Because of the color coding, it's immediately clear if there are any keys that are completely free. (But for this example, we already set our mind on the S key.)

Hovering over a key shows a list of shortcuts in a floater next to our mouse cursor that use that key, eg if you hover over the S key, you see:

• Ctrl: Save File (Window)
• Ctrl Shift: Save As (Window)
• S: Resize (3D View)
• Alt: Clear Pose Scale (Pose)
• Ctrl Alt: Scale B-Bone (Pose)

Clicking on the key will highlight it and filter the shortcut list on the right side, to show only shortcuts with this key in them, ie. the 5 shortcuts we saw while hovering over it. You can click it again to deselect that key and remove the filtering. Any number of keys can be selected at once.

So now your selected context is Weight Paint, your selected key is S, and you press "Add Shortcut". A new shortcut is created with just the S key, and the Weight Paint context added.

If user wants to change the shortcut key from S to A, we want to make sure the shortcut being edited doesn't disappear because of the filtering, so in this case we would automatically select the A key, or deselect the S key.

Similar handling if the user wants to change the shortcut's context from Weight Paint to something else - We would also change the selected context in the left-side context list, to keep the edited shortcut on the screen.
In the shortcut's UI, there is an "Add Context" button, which lets you select Window->3D View->Mesh as the second context for this shortcut.
You can also remove contexts. To delete the shortcut entirely, you would simply remove the final context.

Conflict detection and handling
We check all parent contexts recursively for identical key combinations. This relies on my earlier assumption, about being able to organize contexts into a hierarchy.
A warning appears on the newly added S shortcut: Conflict with "Resize" shortcut from "3D View" context.
There is also now a warning icon in the contex list: Weight Paint (!)
When you mouse-over the S key in the keyboard graphics, there is now a new line:

• S: <none> (Weight Paint) (!)

You enable all of the Ctrl Alt Shift modifier keys to resolve the conflict and make all the warnings disappear.

Operator Search
You already touched on this in the post - There should be a search instead of having to type in the operator's idname. In a perfect world, this would only show operators which are available in all the contexts that this shortcut is assigned to, but I'm not sure if that's possible, since poll() functions can be more complex than just checking the current editor type and object mode.

One way or another, it would probably still be possible for the user to make a non-sensical shortcut+context combinations. For example, if they want to have their shortcut for the Smooth Vertex Weights operator available in the Armature Edit Mode context, and they tried to use that shortcut, it would fail with a poll() error. And I guess that's okay. Powerful tools are never foolproof. Although more useful error messages are always welcome.

Right Click->Assign/Change Shortcut
Currently a tiny input bar pops up and immediately disappears as soon as a non-modifier key is pressed, and it creates the new shortcut. This is fast and can be convenient, but it's not very powerful. I would say in 95% of cases when I used this, I then had to find the new shortcut in the shortcut editor, and customize it to be the way I wanted. So I wish that that popover would be more akin to the new Add/Edit driver popovers. So it wouldn't quite open a fully fledged Shortcut Editor window that then has to be closed, but just a small popover showing everything to do with the shortcut that's about to be created. One difference I would have between this and Add/Edit driver, is to have to confirm the creation of the shortcut by pressing an "OK" button.

Well, that was a giant wall of text, and I'm sure this is 900% out of scope, but you asked for it! :)

Here's a visual example although the software(Wonder Unit Storyboarder) is very different and much simpler than Blender, just to help get the idea across:

This task is not for general help on making keymaps, for this use sites like blenderartist or blender.stackexchange.

In T68884#892054, @Demeter Dzadik (Mets) wrote:

Here's a visual example although the software(Wonder Unit Storyboarder) is very different and much simpler than Blender, just to help get the idea across:

Storyboarder have simple keys layout that allow to display and control them in key-oriented way.
Blender is a wide scope application with complex keys layout, including modals, that's why it have operator-oriented keys editing preferences.

@Dalai Felinto (dfelinto) , @Campbell Barton (campbellbarton) , others: not sure how we can get this task out of the Needs Information From User limbo?

@Paul Kotelevets (1D_Inc)

The context hierarchy system accounts for modal operators, just like in the current system. A more complex piece of software that has a similar editor is apparently Maya

I'm against 95% of UI decisions made in Maya, but I did actually use this hotkey editor years ago to make Maya behave more like Blender - and it was very easy to customize the hotkeys. Complexity can be broken down, and hopefully that's exactly what the context hierarchy does (already). The ideas I described I think change the actual system very little - it mostly just changes how things are displayed.

In T68884#962993, @Demeter Dzadik (Mets) wrote:

A more complex piece of software that has a similar editor is apparently Maya

Yes, it is used there as a viewer with the ability to edit layout (not as main editor), and using this approach as a viewer cause no problems, because viewers just represents data in some readable way.
Developers proposed using such a layout as the main editor, which does not correspond to the complexity of the software.

I haven't done a perfect perfect job of getting my idea across in a more visual sense, but I think this part is relevant to your point, and tackles the issue:

To the right of the input device graphic, is a list of shortcuts available in the selected context. This is where shortcuts can be filtered, modified, added and removed, ie. all the things we can do in today's Blender.

This is effectively the exact same menu that currently exists in Blender, and it would continue to function 95% the same way. So I don't think you'd be losing anything. Certainly not the ability to have an overview of assigned operators in a context. That would totally still be there, and it would be one of the three top-level UI elements.

In T68884#963599, @Demeter Dzadik (Mets) wrote:

To the right of the input device graphic, is a list of shortcuts available in the selected context.
This is effectively the exact same...

Yes, I know that.
But the problem is that the proposal made by the developers does not include such a list of shortcuts available in the selected context. They want to make it even more primitive than in Wonder Unit Storyboarder style, with only graphic and no list.
So we both have to explain this issue to devs, not to me, right?

Ah, for sure, I'm all for that :) But looking at the roadmap and weekly reports, the devs are understandably busy with more important projects, so I think this area is fairly low priority atm. Which is fair, the current system is completely functional, it's just hard for new users is all.

I wonder if I could at least partially implement a prototype of my idea in python, as a proof of concept if nothing else... I'll keep that on my mind, but no idea when I might find the time.

@Campbell Barton (campbellbarton) do you plan to work on this short-term-ish?

While I think we all agree that the keymap editor/system needs work, I'm not sure if we should make this a goal for the 2.9x series.
The current UI team plan is to focus on wrapping up the 2.8 project for that series and avoid adding new projects. The keymap editor changes will take a while to complete and take attention from other tasks. Especially if we want to do it properly.

(I'm not at all discouraging design work and feedback though, just questioning if the UI team should prioritize this right now.)

Hi, I have question regarding to this report I created https://developer.blender.org/T78628 . Does this also falls into keymap System refactor? It's sounds like one of the issue of looses the ability to access key-map preferences, but the one I mentioned is it replacing other keys while creating new set.