Expose viewport gui_find_control to scripting

[cdoise-vbg]

Resubmitting relevant changes from this pull request to expose gui_find_control to GDScript. Another pull request had already been merged in that covered getting the mouse_over control
#84909

Usage:

var control_under_point = get_viewport().gui_find_control(get_global_mouse_position())
print(control_under_point)

[AThousandShips]

The bind methods aren't just exposed to GDScript, they're also available to C# and GDExtension, please update your commit message accordingly

[Sauermann]

var control_under_point = get_viewport().gui_find_control(get_global_mouse_position())

This example will not work when the Canvas layer has a non-default transform, since you are mixing different coordinate systems:

• CanvasItem.get_global_mouse_position() returns the position in canvas layer coordinates
• Viewport.gui_find_control() accepts the position in viewport coordinates.

Please change your description to:

var control_under_point = get_viewport().gui_find_control(get_viewport().get_mouse_position())

[cdoise-vbg]

Thank you for the feedback. I'll work on updating the description. Two scenarios I was interested in supporting with this are: - Second player with a custom gamepad-controlled virtual cursor being able to click on Controls. - Testing logic that can do basic checks for the presence of a Control at a particular coordinate on-screen.

…

On Tue, Dec 19, 2023 at 8:29 PM Markus Sauermann ***@***.***> wrote: var control_under_point = get_viewport().gui_find_control(get_global_mouse_position()) This example will not work when the Canvas layer has a non-default transform, since your are mixing different coordinate systems: - CanvasItem.get_global_mouse_position() returns the position in canvas layer coordinates - Viewport.gui_find_control() accepts the position in viewport coordinates. Please change your description to: var control_under_point = get_viewport().gui_find_control(get_viewport().get_mouse_position()) — Reply to this email directly, view it on GitHub <#86343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATYQEV2YOZLEJFKUPYFX3J3YKI5QDAVCNFSM6AAAAABA33EBWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRTG4YDAOBWGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cdoise-vbg]

I updated the description to be more specific about which coordinates are expected based on comments above. Should I include the specific code example too in that particular comment location? (meaning: "var control_under_point = get_viewport().gui_find_control(get_viewport().get_mouse_position())").

I also need to go back and fix up the 2 commits so that they appear as 1.

UPDATE:
Commits have been squashed so they appear as 1 commit.

[Sauermann]

Suggested change

	viewpoint coordinates provided by the point parameter. If no [Control] is at that point, returns null.
	viewport coordinates provided by the point parameter. If no [Control] is at that point, returns null.

[AThousandShips]

This should also be a single line, the current text is two separate paragraphs

[cdoise-vbg]

Thank you @AThousandShips for the rewording of the documentation. I've committed that from the button to accept suggested changes in the comments above. Should I now go back and squash those two commits back down to one?

[name212]

@AThousandShips will this pull reqest be merged?

[AThousandShips]

It hasn't been approved yet, only once approved will it be considered for merger, we're currently in feature freeze for 4.3 so this can't be merged until after 4.3 has been released, but again after approval

[cdoise-vbg]

Do I need to do anything in particular to request approval or further comments for the latest check-in from December 31?

[AThousandShips]

Not that I know, but once 4.3 has been released you can write in the developer chat and see if anyone can take a look, feel free to join already to keep up to date with development

[badsectoracula]

I fixed the conflict and did a quick test with an editor script and this seemed to work fine and as expected.

You may want to squash the commits again to 1 and fix the conflict.

[Sauermann]

Please note, that Viewport::gui_find_control doesn't take embedded windows into account.
So the caller of this function would need to make sure, that there is no embedded window at the specified position.
Otherwise the function could return a Control-node, that is hidden behind an embedded window.

So I'm not sure, if exposing this function as it is, is a good idea, because people could get unexpected results, if they are unaware of these details. This implementation detail also caused problems inside the engine, which was recently discovered: see #99849

Would the following idea be better?
Expose a function Node *Viewport::gui_find_node_at_position(const Point2 p_position), which returns

• the embedded window at p_position or otherwise
• the Control node at p_position or
• nullptr, if neither of the above conditions fit.