You didn’t mention it, but based on the way you’re saying things I’m assuming your add-on has a modal operator. I strongly believe these key conflicts would not be a problem if add-on devs had access to modal keymaps in the same way that the Knife Topology Tool (mesh.knife_tool), the Edge Bevel (mesh.bevel) and other built-in operators have.
All Python modal operator demos suggest that we react to raw key events (‘LEFTMOUSE’, ‘BACKSPACE’, ‘LEFT_CTRL’ etc.), but the built-in modal operators handle it way better.
Essentially, you don’t care what key combo is being pressed, you only care what action it translates to – ‘CANCEL’, ‘CONFIRM’, ‘NEW_CUT’, ‘INCREASE’ etc.
So here’s an appeal to @ideasman42 to please consider adding modal keymaps to Python operators. If your modal operator is running and the users presses a key combo to an action of that operator, even if that same key combo is also used by other operators, the event goes to you first since you’re the one that’s running. That’s how you get priority, you won’t need to worry about disabling other keymap items.
All the tech needed for this already exists, but it needs to be exposed to Python.
We’re talking about…
- a way to define a bpy.props.EnumProperty with all the modal items,
- a way of associating them with your operator,
- for the event loop to include the action identifier in some attribute of the
Eventobject sent to the Python operator’s.modal()function.
(I can’t use a 3rd link in my post because I’m a recent user, the relevant source is this:https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/mesh/editmesh_bevel.c$656-802)
This would let the Input preferences screen show your add-on modal keymap and the user can decide what key combo they want to use for each action, like they already do for the built-in modal operators:
