-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be more conservative with Mouse Filter defaults (most controls should have Ignore) #788
Comments
As mentioned in #881 , I would say PASS as the default is more desirable. Otherwise we get similar situations to before, where inputs are not being recognized by Nodes when the user would expect otherwise. (Say you listen to input_event in a Control set to Ignore.) |
If a scene have UI elements mixed with pickable PhysicsBody, it will often cause issues because Controls Node have mouse clicks priorities, and a lot of will eat the inputs even with PASS, as PASS doesn't pass the inputs to non-controls nodes. This is a very common problem. Also it just makes 0 sense for ColorRect and TextureRect to be STOP as default at all, since most people use them for shaders. |
There are currently three options for
Why there is no
If implementing |
You have misunderstood MOUSE_FILTER_PASS . It does what you are saying process should do. |
But I suppose that implementing
|
It is implicit that any siblings will also receive the event if no parent eats it. That is the normal course of input propagation. Please don't spread misinformation in a topic that isn't about what the process modes do, but where they are meant to be used. This proposal wasn't addressed because nobody could be bothered to do so yet. |
There must be misunderstanding somewhere. This is about
Unless child Control has mouse filter to ignore, button will never receive a gui event (as in react to mouse movement or get call to |
If the Child has mouse filter mode set to Pass, the button will receive the event just fine. |
It will not and it is easy to verify with the provided snippet, this is how current architecture works. I am using Godot 4 from master. If you would like to continue this discussion I think it is better to use developers rocket chat for that. As I understand we both agree that For record, even if theoretical |
An assessment of the current state is available in #3613. |
Since I couldn't find this info in the documentation, PASS:
IGNORE:
STOP:
These are the Controls that are currently STOP but don't handle any input themselves and I think should be changed to PASS by default:
Of course, this breaks compatibility so it probably won't happen for a while. |
What is the reasoning for the base Control node being set to stop by default? This caused me many headaches in the past until it happened enough that I was able to identify the problem. I believe if the user wants a mouse blocker and not a generic control, they should have to specify that explicitly. RichTextLabel and Label having different mouse handling defaults is also problematic. I also suggest against using Pass by default pretty much anywhere simply because the way it actually works is not intuitive as evidenced by the other proposal to rename it. In addition, I subjectively just don't understand why I should expect input to be passed to the parent rather than to whatever node is behind. A click feels like a laser shot through the screen that is captured by whatever is in front, and I don't see why that laser should care about the scene tree instead of the rendering order. |
Describe the project you are working on:
A hobbyist game project involving a lot of UI work.
Describe the problem or limitation you are having in your project:
Given that most controls (including the generic Control node type) are set to mouse filter stop I am constantly surprised to discover my UI elements cannot be interacted with due to invisible boxes overlapping them.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I'd recommend all nodes to have mouse filter
pass
orignore
unless they them-self implement an interactable UX. Container type nodes should not have mouse filterstop
unless they are intended to overlap other content such as a popup.Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
I may misunderstand how exactly
pass
works but I would expect containers to have the behaviour that they will allow children to handle mouse events by default. If setting containers toignore
is problematic than eitherpass
should be used or a new type should be created.If this enhancement will not be used often, can it be worked around with a few lines of script?:
It can be "worked around" by constantly changing all nodes to mouse filter
ignore
. I am tempted to do so with a plugin. But I believe this change will make things easier for everyone.Is there a reason why this should be core and not an add-on in the asset library?:
See above.
The text was updated successfully, but these errors were encountered: