godot
godot copied to clipboard
GraphNode doesn't respect mouse filter.
Tested versions
- Reproducible in v4.2.1 Stable
- Windows 10
System information
Vulkan API 1.3.260 - Forward+ - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1660 Ti
Issue description
GraphNodes do not respect their mouse filter. Setting it to Ignore, Pass, or Stop does nothing.
In previous versions, GraphNodes could be set to be a Comment, and that would cause it to ignore mouse input. But in later versions this feature was removed.
I am attempting to make a node that I can 'lock', and have it ignore inputs and allow click-drag select to start on top of it. But when 'selectable' and 'draggable' are set to false, it still takes priority over mouse input over the GraphEdit. When the user attempts to click-drag select, the mouse instead turns into the dragging icon and does nothing.
Here is a video of my larger project where I discovered the issue. The first part is the intended behavior in version 4.1.1, while the second part is in v4.2.1 stable.
https://youtu.be/sqXpXIS24iU
Steps to reproduce
- Create a new graph edit
- Create a GraphNode
- Set that GraphNode's mouse filter to Ignore or Stop
- Notice that it doesn't affect it's behavior.
- Setting Selectable and Draggable to false, still takes mouse input priority
Minimal reproduction project (MRP)
From these docs:
The control will not receive mouse movement input events and mouse button input events if clicked on through _gui_input. The control will also not receive the mouse_entered nor mouse_exited signals.
I've rechecked it and (from what it looks) it works exactly the way it is described in docs. Maybe the issue would be more apparent if you provide us with MRP from your video (with the 'lock' node)?
If I recall correctly @Geometror had plans to reintroduce a brand new "Comment" node specifically with this behavior after the GraphNode rewrite that was done. I'm not sure where that work stands, but maybe they can provide some insights.
No, it's not working the way the docs describe, but perhaps I wasn't specific enough. I provided an MRP.
Setting a GraphNode's mouse filter to Ignore, while it is inside of a GraphEdit, doesn't do anything. It still responds to mouse_entered and mouse_exited signals, and you can't initiate a drag-select if you click right on top of it. There is no reason to have a GraphNode outside of a GraphEdit.
This behavior continues in 4.2.2 stable. I have since reverted to the 4.1 branch as it still has the 'comment' feature for GraphNodes.
Maybe it isn't a bug, and just missing functionality,
If I recall correctly @Geometror had plans to reintroduce a brand new "Comment" node specifically with this behavior after the GraphNode rewrite that was done. I'm not sure where that work stands, but maybe they can provide some insights.
Ah, okay. Well I'll keep an eye on updates and continue on the 4.1 branch.
It still responds to mouse_entered and mouse_exited signals
@Yellow768 So you've tried to bind mouse_entered()
and/or mouse_exited()
signals to the Node with MouseFilter set to Ignore
and this Node still receives events in these callbacks? I've checked you MRP and while the property is set to Ignore
-- it doesn't receive the events mentioned above.
Ok, further testing, setting the mouse filter to ignore in the editor drop down menu doesn't seem to work, but setting it in the code does cause it to actually ignore the mouse.
But, the same problem persists that you can still drag the node if Selectable and Draggable are set to true. And if you click and drag anywhere on the grid, you can create a box selection. But if you start trying to drag on the Node, if draggable and selectable is off and mouse filter is set to ignore, it still doesn't allow you to make a box selection.
https://www.youtube.com/watch?v=_7GHIulKy9Q
So maybe not a bug, just functionality that I would like to have but isn't implemented yet As Naros said
If I recall correctly @Geometror had plans to reintroduce a brand new "Comment" node specifically with this behavior after the GraphNode rewrite that was done. I'm not sure where that work stands, but maybe they can provide some insights.
Oh so you're connecting to a signal in the parent's script. That might be the issue. I'll investigate if it's a bug or it should work this way.