I am trying fix T72069, which I reported myself. I need some pointers regarding shortcuts and GHOST

Hi! New nerd on the block …

I no longer work towards a fix. It appears this issue is in progress and in the hands of Campbell Barton


Using T72069 as a tracer bullet to get started.
Starting at WM_Main() and all the event-handling I can’t seem to find my way to where
keyboard shortcut’s end up being processed. My working theory for now is that the introduction
of a flexible context-concept (compared to 2.81a) messe up the operator. Using debug I found that
the call to the C-function edbm_do_smooth_vertex_exec() happen when I use context-menu, but the keyboard-shortcut never found it’s way.

Anyone who can give pointers?
Who knows these parts best?

Open up space_view3d.py and find the vertex menu. Tweak the entry for smooth vertices so it looks something like this:

        layout.operator_context = 'INVOKE_REGION_WIN'
        op = layout.operator("mesh.vertices_smooth", text="Smooth Vertices")
        op.wait_for_input = False
        op.factor = 0

After you do that, open Blender and replace the instance of smooth vertices in your quick favorites menu with one taken from your modified menu entry.

When you add an operator to the quick favorites menu, the operator’s properties are copied pretty much verbatim. If the operator has properties that aren’t shown in the redo panel, and the default values for those properties aren’t the ones you want, you’re out of luck; there isn’t an easy in-interface way to change them.

The same constraints apply to the operator’s context; if you add an operator to the quick favorites menu from an entry that calls it with EXEC_DEFAULT, but you want it to call it with INVOKE_DEFAULT (or similar), there’s no easy way to do that.

As far as I know, Blender doesn’t have any operators with a user-facing ‘Use Modal’ property. It could come in handy, though.

Thanx for replying, but I already tried a few things like that and concluded that it’s not as easy as fixing the python part. Tried what you suggested though, it made no difference…
So I dug into the ‘real’ code :wink:

I’m almost certain that it’s related to recent, obviously incomplete, changes in how the event-loop handles key-events and possibly short-cuts RNA. Still trying to find the path from a key-stroke to the implementation in editmesh_tools.c.

I must be misunderstanding the issue, then. T72069 seems to focus on how WM_operator_type_modal_from_exec_for_object_edit_coords handles its wait_for_input property, not initializing the modal UI until the user left-clicks when wait_for_input is true. And, near as I can tell, the answer to that issue hinges on changing how the modal UI is initialized in op_generic_value_invoke, rather than debugging the event system.

Beyond that, the operator appears to works as-designed on my system (Win10, latest daily). Calling it from a menu (where the context’s been set to EXEC_DEFAULT) produces the expected non-modal behavior, while calling it from a shortcut — with wait_for_input set to false — produces the same behavior as the active tool. You can’t call a non-modal version of the operator from a shortcut, but that’s more of a feature request than a bug.

The issue was reported as Smooth vertices not working.
It appeared that it worked when not using a shortcut but I
found it randomly changed the factor in some cases.

I recently noticed that there is another smooth thingy happening, now bound to the same key I’ve used but actually modal inputting factor using mouse. This is not what I reported on.

However, I see that making these operators modal is a thing i missed.
I raised a concern since it breaks my workflow.

Still, the current behavior is not stable/useful even with modal if you want to add shortcut.