Editor plugin receives mouse events even if the Spatial gizmo is being manipulated

[Zylann]

Godot 3.0.2

I made a plugin which lets the user paint on a terrain. However, I noticed that if I select the terrain node and try to drag the usual Spatial gizmo to move it, if my click lines up with the terrain, I end up painting and the gizmo doesn't reacts (because my plugin got the event and captured it).

If I don't capture the event, I end up both moving the gizmo, making a square selection and painting all at the same time, which get messy really quickly.

The gizmos should receive input first and capture it, before the event gets forwarded to the plugin. Or is there any other way to avoid this?

[omicron321]

From docs, I see you could use http://docs.godotengine.org/en/3.0/classes/class_node.html#class-node-set-process-unhandled-input so your plugin receive inputs, at a lower priority. See http://docs.godotengine.org/en/3.0/tutorials/inputs/inputevent.html

[Zylann]

@Omicron666 but is this even applying to editor plugins? The input IS going to be handled if for example I put an object under the terrain and will get selected, so my plugin won't receive anything.

[KoBeWi]

Can anyone still reproduce this bug in Godot 3.2.1 or any later release (e.g. 3.2.2-beta4)?

If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

[Zylann]

It still happens in my plugin. Assuming my plugin and GridMap are implemented similarly, then it's the same as https://github.com/godotengine/godot/issues/19860#issuecomment-644259745

But I can try making a GDScript EditorPlugin project to show it if you want.

[KoBeWi]

Maybe let's just wait until the other issue is fixed (it's easier to test) and then check this one.