2
$\begingroup$

Someone just asked here about adding a custom hotkey to an add-on that I made a some time ago. This add-on, for some reason, doesn't show any hotkey setup options when you right click on it like most operators show in Blender.

After doing some research, and looking through add-ons that I have made in the past, it appears that registering operators like...

bpy.utils.register_class(SomeClassName)

...doesn't allow the operator to have the hotkeys, but registering the entire module...

bpy.utils.register_module(__name__)

...does show the hotkey controls.

Is this intended behavior? Is there anything to do if you don't want to register the entire module like this?

Edit:

For the script that I linked to, simply registering the module instead of the operator class does not provide the user with the hotkey controls.

Here are some screenshots showing what I mean in case of any misunderstandings:

enter image description here

enter image description here

$\endgroup$
2
$\begingroup$

An operator represents an action or task that can be performed in blender. A button is blender's GUI representation of an operator which allows the user to initiate the action, while a keyboard shortcut is a non-gui method of executing an operator. Keyboard shortcuts can be edited in the user preferences and each belongs to a group that (should) represent the context that it is available. For example, the loop cut operator can be found in the 3DView/Mesh group so is available when editing mesh objects.

When right clicking on a button, the "Change Shortcut" and "Remove Shortcut" menu items are available if the button's operator has a shortcut assigned to it. See interface_handler.c

The "Add Shortcut" menu item, represents blender having some idea of what group the shortcut should be added to. Blender "guesses" the group based on the operator's bl_idname property and the menu option is only available if a valid group can be guessed from the operator's name. See wm_keymap.c where you will find the available group names that can be used. The group names used there are the uppercase version of the first part of the bl_idname of the operator with the _OT part being optional. For example giving your operator bl_idname='screen.my_operator' will enable the add shortcut menu item which will add a shortcut that will be found under "Screen" group in the shortcut settings.

$\endgroup$
  • $\begingroup$ Hmm...Is it best practice to make the bl_idname addon_name.operator or category.operator or category.addon_name.operator? I have been using the first method to prevent duplicate operator names... $\endgroup$ – JakeD Jan 7 '17 at 13:52
  • $\begingroup$ Actually, it seems that a bl_idname can't have more than 1 "." character...any advice on this? $\endgroup$ – JakeD Jan 7 '17 at 15:04
  • 2
    $\begingroup$ @pycoder - cat.opname is the general design, so cat.myop becomes bpy.ops.cat.myop as addon numbers are rising, I think using addon_name.op_nameis a good idea, particularly for larger addons. If we define shortcuts for operators in each addon then the change shortcut will be available, regardless of operator name. I think consider the add shortcut of limited use - maybe even a builtin operator only feature - unless you can get a dev to change it, maybe add a category choice to the popup when setting the shortcut. $\endgroup$ – sambler Jan 7 '17 at 16:31
  • $\begingroup$ As unused keys are hard to find, the use of two-key shortcuts will probably start rising, maybe using one two-key combo to get a pie menu for every operator in an addon? If you are unfamiliar with two-key setup, try holding D like a modifier key and press Q. Select stroke editing and try again. Then settings.... $\endgroup$ – sambler Jan 7 '17 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.