Shortcut Deconflicter - handle many operators with one key

Coding Released Scripts and Themes
1

(Upped to gumroad to be searchable)

3 Likes
2

Realized was not considering press, click, double click, values before. And blocking non drag pie menus.
Small update for the 1 downloader that might have gotten it from this link : D

2 Likes
3

Suggested by the repository reviewer, the addon now tries to filter operations not available to sub contexts (like sculpt brushes in edit mode).Still, because of how Blender manage contexts might not be enough for the repository. Blender does the same silently when you press a shortcut that does not work (like local view with not objects selected). The difference is that in some cases the list will show you the operator (because it is available) and the addon will communicate (differently from blender) that it could not execute for respective reason.
Will see :slight_smile:

4

Logic is pretty solid right now with a mode map to cross check conflicts.
Trying to find ways to break it with out of ordinary shortcut combos.

5

Small correction!! Changes were not persistent… now they are.

Reached a clean proofed against other-addons-shortcuts state that I don’t think will be able to evolve from.
The menus and conflicts work just like you imagine: if marked from the deconflicter panel, they only appear where there would be a real conflict with other shortcuts and are filtered by the poll (so non exec commands should never, or almost never, appear in the menu).
Entries in keymaps are minimal and support the not grouping of “non exec” operations in subsections or submodes.
The “issue”: screen and window shortcuts are global, so you should avoid creating shortcuts combining with those there. Blender default already leaves that door open on it’s keymaps. The good thing is that the addon will better expose and list the conflicting operators.

Well… there are too many shortcuts for me to test, and believe me… I’ve been trying. Need you guys help to find blind spots!

Thank you!

6

Findings documentation:

Blender Keymap System — How It Really Works?

Part 1 — How Blender builds the UI keymap list

Three independent source lists:

  • Base (keyconfigs.default) — Blender native shortcuts, immutable.
  • Addon (keyconfigs.addon) — only what addons registered.
  • User (keyconfigs.user) — only what the user touched: modifications of Base or Addon shortcuts, and user-created bindings. If the user never touched a shortcut, it does not appear here.

How the final UI list is assembled:

  • User modifications of Base and Addon entries replace the originals in their original position.
  • New user-created bindings are added at the end of their keymap section.
  • Addon entries are positioned according to head=True/False at registration time.
  • The result is a single concatenated list visible in Preferences.

Part 2 — How Blender navigates shortcuts within the list

Keymap hierarchy — children before parents:

  • Mesh → 3D View → Screen → Window.
  • Global keymaps (Window, Screen, Frames, User Interface) are always active regardless of context.
  • Mode-specific keymaps (Mesh, Armature, Sculpt) are mutually exclusive — only one is active at a time.

Within each keymap section — top to bottom:

  • The visual list is the reverse of the internal array.
  • The Value option (Any, Press, Release, Click, Double Click, Drag, Nothing) also makes an internal key combo hierarchy — Press is more specific (even than Any) and fires before all, even at lower positions on the list.
  • head=False inserts at the end of the internal array → top of the visual list → processed first.
  • head=True inserts at index 0 of the internal array → bottom of the visual list → processed last.
  • The first operator whose poll() passes is executed — the rest are ignored.
  • Blender does not detect or resolve conflicts — it simply executes the first match in this bottom-up–top-down “hierarchy”.

Part 3 — How the addon scans for real conflicts and resolves them

Identifying real conflicts:

  • Two or more operators sharing the same combo in keymaps that can be simultaneously active constitute a real conflict.
  • Conflict candidates list is built comparing the native keymap vs user and addon generated entries. If a concurrent shortcut is found under global-any, parent-child or intra-child relationships, it is listed. Sibling concurrent shortcuts do not constitute a conflict.
  • Value option hierarchy has to be ignored because the addon overrides all with Press to guarantee being called with priority at the top of the lists.
  • The final UI list is not directly accessible via the Python API — Blender renders it internally by concatenating the three source lists. The addon must therefore reconstruct it manually to identify real conflicts.
  • To avoid false conflicts from user modifications, the addon simulates the UI list with updated entries changed or added by the user, instead of using the base and addon original keymaps directly. Two rules apply:
    • When User has a modified entry for (keymap, operator) — meaning the user changed the combo of an existing Base or Addon shortcut — the original entry is excluded. The modified version is what exists in the UI list;
    • When User occupies (keymap, combo) — either by modifying an existing shortcut to use that combo, or by creating a new entry with it — any Base entry previously using that combo is excluded. The user’s version is what exists in the UI list.
  • These rules are not enforced by Blender — they are heuristics implemented by the addon to reconstruct what the UI list represents.

Resolving conflicts:

  • For each managed conflict, the addon registers a conflict.show_menu interceptor, with a Press value type, in every keymap where a conflicting operator exists.
  • The interceptor is registered with head=False — placing it at the top of the visual list in each relevant keymap section.
  • This ensures the menu appears before any conflicting operator executes, regardless of their individual positions in the list.
  • When the menu opens, operators are filtered by current context — only those whose keymap is active in the current mode are shown. However, operators from global keymaps (Window, Screen, Frames, User Interface) always pass this filter since they are active in any context. This means a conflict involving a global keymap may show operators that Blender would silently cancel in the current context not to execute incompatible commands — the addon will still try to filter these options from the menu with a native poll(), or notify when the operation can’t be executed.

Editor keymaps as containers:

  • Parent “(global)” keymaps like 3D View, Node Editor, Image Editor are hierarchical containers — they are never the active context themselves.
  • You are always in a specific child context: Object Mode, Mesh, Sculpt within 3D View; Shader Editor or Geometry Node Editor within Node Editor; etc.
  • Shortcuts registered in a parent keymap are active in all its children, but the parent itself has no independent existence as an active context.
  • This makes it impossible to manage conflicts independently per child mode at the registration level — and the interceptor must be registered separately in each child keymap where there might be a conflict.

API limitations:

  • There is no move method in KeyMapItems — reordering already registered items is not possible.
  • Operator poll() is unreliable outside its native invocation context — mode filtering should be done via keymap mapping, not by calling poll directly.
  • The head=True naming is counterintuitive — “insert at the start” of the internal array means the last to be processed, not the first.
1 Like
7

Implemented better filtering to the conflict lists making them more consize and improved parent-child context relationship visualization for better conflict and context-aware menus understanding

1 Like
8

v 2.0 : )

New feature - Adjust Context - to easily reassign user shortcut context for improved conflict menu management, by remapping a custom shortcut Blender might have misplaced in a broader context (like a snap toggle in Window instead of 3D View). Improved keymap hierarchy map for more accurate conflict detection and editor root evaluation.

9

Got declined as for the sensitive area the tool touches.

That is ok : ). It’s been pretty stable on my daily use and I’ll keep updating and making it safer for you guys!

Will leave the extension availabe at the repository, as declined not to loose those concerns and history.

Let me know if you find anything needing to be fixed while using it. Will keep updating it.

10

Following the revisor feedback, v2.1:

Keymap backup and recovery feature — restores custom shortcuts without resetting Blender’s internal change tracking, unlike the native keyconfig import.

Orphaned user-created operator detection in the conflict list — flags shortcuts whose operator no longer exists in Blender, typically after a major updates.

2 Likes
11

Decided to change recover feature to restore from userpref.blend backups instead of addon’s JSON. Not as chirurgical, but more consistent and secure.

12

2.1.3
Some bug fixes for the few interested : )

13

v 2.2.0

Keymap hierarchy accurately reflects Blender’s own Preferences > Keymap structure, with correct labels matching what you see in the interface, including the “(Global)” suffix where appropriate.

Fixed a bug where user-created shortcuts were incorrectly shown as modified native shortcuts.

New “Misplaced Shortcuts” feature — detects shortcuts that might have been incorrectly assigned to a, mostly broader/global, context and helps you move them to the right place with one click.

1 Like
14

v. 2.3.0
Auto-merge option to always toggle user-generetated/modified shortcut conflicts into context aware menus.
Improved misplaced shortcut detection.
Conflict origin filters.

(Transferred it to Gumroad to be searchable)