I wanted to edit the official pie menus add-on so that instead of Click-Style Intraction ,releasing the pie key without moving the mouse would cause the key to continue its previous function (exp. pressing 'tab' without moving the mouse, switch to edit mode directly instead of appearing the annoying static menu which slow me down.) Reason: Maintaining my muscle memory.

However as I digged into it, it appeared that the new official pie menus add-on is twisted with the blender source itself...

So I want to ask if there is anyway I can achieve this with a python code and editing ui_pie_menus_official.py (within the /2.76/scripts/addons folder) without needing to compile a new branch?

There were a couple of solutions reached my mind but I have no idea about how to practically do it: -Somehow simulating a 'HOLD' option instead of 'PRESS' for km.keymap_items

-for example if the tab key pressed and if the mouse have moved (kmi = km.keymap_items.new('wm.call_menu_pie', 'MOUSEMOVE', 'ANY')), do kmi.properties.name = 'VIEW3D_PIE_object_mode' else just go to edit mode (ops.object.mode_set(mode='EDIT', toggle=True))

-if the mouse was within the pie circle (or inside pie_menu_threshold) go to edit mode instead of bringing the pie menu.. (However I thinks this requires compiling some C++ codes!)



1 Answer 1


I can think of two approaches that don't involve altering the pie menu addon.

First is to alter the keyboard shortcuts, blender can use any key as a modifier so you can keep ↹ Tab to toggle edit mode and hold E and press ↹ Tab to show the pie menu. The standard edit mode shortcut is left in place, the pie menu addon just gets the tab key before the default shortcut.

Altered keyboard shortcut

Another approach that gets closer to your idea is to create an addon that runs an operator on a timer to decide after the set time if it should toggle edit mode or show a pie menu. As it is, this example is awkward to use but could probably be improved with a bit more work. The full addon can be found here with the main operator showing the idea below. The mouse positions passed into the operator's modal() are from the previous modal() call rather than the initial execute, this leads to the mouse needing to be moved just as the timer is triggered to get the menu to show.

class TimedEditMode(bpy.types.Operator):
    """Go into edit mode if tab is held down"""
    bl_idname = "wm.timed_edit_mode"
    bl_label = "Timed Edit Mode"
    _timer = None

    def modal(self, context, event):
        if event.type in {'RIGHTMOUSE', 'ESC'}:
            return {'CANCELLED'}

        if event.type == 'TIMER':
            move_x = abs(event.mouse_x - event.mouse_prev_x)
            move_y = abs(event.mouse_y - event.mouse_prev_y)
            move_threshold = context.user_preferences.view.pie_menu_threshold

            if move_x > move_threshold or move_y > move_threshold:
                return {'FINISHED'}
                bpy.ops.object.mode_set(mode='EDIT', toggle=True)
                return {'FINISHED'}
        return {'PASS_THROUGH'}

    def execute(self, context):
        wm = context.window_manager
        self._timer = wm.event_timer_add(time_to_wait, context.window)
        return {'RUNNING_MODAL'}

    def cancel(self, context):
        wm = context.window_manager
  • $\begingroup$ Yeah, nice trick! The timer event... Both of your solutions work perfectly. (for the first one 'wm.call_menu_pie', 'MOUSEMOVE', 'ANY', key_modifier='TAB'). I probably work on the second one to make it smoother. Thanks so much for putting your time and writing the script for me. (As I'm leading to believe that the pie menus are now probably hard-coded, I don't think of any better solution an the moment; so cheers!) $\endgroup$
    – Ali
    Feb 7, 2016 at 12:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .