-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Document when to use _unhandled_key_input
over _unhandled_input
#42100
Document when to use _unhandled_key_input
over _unhandled_input
#42100
Conversation
doc/classes/Node.xml
Outdated
@@ -101,7 +101,8 @@ | |||
Called when an [InputEvent] hasn't been consumed by [method _input] or any GUI. The input event propagates up through the node tree until a node consumes it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the right language is used here. The call doesn't actually "propagate" from what I can tell (see SceneTree::_call_input_pause
).
The input event propagates up through the node tree
This language might mislead the user into thinking the call is repeated on parents until it is handled, or until the last parent. This is not correct. call_input_pause
only calls the method on the node it is registered to call on. For example, MenuButtons are registered to receive unhandled_key_input
. The _unhandled_key_input
method is only called on the MenuButton - not parents, and not children.
I would probably change this to something more accurate:
"_unhandled_input
is called on every node which is registered to receive it until one of the nodes handles the input."
However this relies on the information that "It is only called if unhandled input processing is enabled" so this might be better to place after the next line
The usage of the word "propagates" may also mislead the user into thinking at Object::propagate_call
is used behind the scenes for this functionality.
It may also be worth noting that the order of the nodes it is called on is based on order in the scene tree - based on Node::is_greater_than
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P.S. I know this isn't part of the PR but I thought since we are here, let's discuss
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right on all the points, but to be honest I don't think we should care that much.
The function is indeed not called on all the nodes, as they indeed have to implement the method. I am not sure it is worth mentioning to the user, as they probably know know an unexisting function cannot be called.
Regarding the "propagate" term, in the end it's the same. It's a similar behavior to calling Node::propagate_call
, as the node order produced by Node::is_greater_than
will lead to the same order as what a reversed propagate_call would do. That's why the documentation mentions "propagates up through the node tree".
We have to write the documentation from the user point of view, what happen behind the scene for performance reasons (like adding the nodes to a group, so that the function is only called on specific nodes, etc...) is not important. What matters is the end result.
Oldie, but still goodie? Would need a rebase and maybe re-discussion with current GUI experts. |
Yeah it's looking good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved in PR review meeting to merge once rebased.
The discussion on existing language is not fully resolved but this can be reworked in a future PR / discussed in another issue.
a8e89b4
to
3913fda
Compare
Unhandled input processing was changed a bit, now there are 3 stages:
|
@groud Would you mind incorporating the changes that bruvzg mentions? (and fixing the typos mentioned in the review). Your additions touch directly on the need to use keyboard shortcuts, so I guess |
Closing in on a 3 year anniversary here... @groud are you able to do the required adjustments? |
I missclicked the "ready for review" button, sorry. I'll have a look today |
3913fda
to
0e4c027
Compare
Updated, let me know what you think. :) |
0e4c027
to
ae4a60e
Compare
_unhandled_key_input
over _unhandled_input
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes describe the implementation correctly as far as I can tell.
ae4a60e
to
bc33add
Compare
Phew, finally done with this one! One day shy of a 3 year anniversary :D Thanks! |
As discussed in IRC with @reduz and @EricEzaM