BaseButton: multitouch support

[Kazox61]

Closes Partially implements godotengine/godot-proposals#3976

I added support for multitouch by using screen events instead of mouse events when touch screen is available.

Add a Touchscreen Only boolean property to BaseButton (similar to TouchScreenButton's existing property).

I couldn't figure out how this boolean should work.

Do we want to have a hover if the touch started outside and dragged inside the button?

[Calinou]

I couldn't figure out how this boolean should work.

Something like this should be at the beginning of NOTIFICATION_DRAW:

godot/scene/2d/physics/touch_screen_button.cpp

Lines 140 to 142 in ecfe34f

	if (!Engine::get_singleton()->is_editor_hint() && !DisplayServer::get_singleton()->is_touchscreen_available() && visibility == VISIBILITY_TOUCHSCREEN_ONLY) {
	return;
	}

This should also be done where input is processed, so that input is skipped if the button is invisible because the user doesn't have a touchscreen currently.

[Kazox61]

I couldn't figure out how this boolean should work.

Something like this should be at the beginning of NOTIFICATION_DRAW:

godot/scene/2d/physics/touch_screen_button.cpp

Lines 140 to 142 in ecfe34f

	if (!Engine::get_singleton()->is_editor_hint() && !DisplayServer::get_singleton()->is_touchscreen_available() && visibility == VISIBILITY_TOUCHSCREEN_ONLY) {
	return;
	}

This should also be done where input is processed, so that input is skipped if the button is invisible because the user doesn't have a touchscreen currently.

Thanks for the instructions. Added the boolean touchscreen_only.

[AThousandShips]

You've accidentally merged the master branch into your branch incorrectly taking ownership over the changes, to prevent this make sure you rebase to update your branch, to fix this you need to remove the merge commit with master and rebase instead, see here

[Kazox61]

Is it now fixed?

[Alex2782]

I tested it on Android and didn't find any critical regressions. We can still optimize some minor things in the code.

[Alex2782]

Do we want to have a hover if the touch started outside and dragged inside the button?

Hover test, Video

Screen_recording_20260324_041445.mp4

I believe the following bug fix is ​​needed to solve it properly.

Only after that is it possible to receive InputEventScreenTouch, when the finger inside the button is no longer touching the touchscreen.

			if (!over) {
				over = gui_find_control(pos);
			}

here in the Viewport: https://github.com/godotengine/godot/blob/master/scene/main/viewport.cpp#L2238-L2251

It still needs to be checked whether this change leads to regressions.
EDIT: A safer/better solution would probably be to force an InputEventScreenDragevent with pressed = false (if possible) instead.

What also doesn't work yet is the multitouch hover effect; a maximum of 1 button changes the hover status.

[Kazox61]

Do we even want to have a hovering for touch input, since hovering is technically not possible with a touch input.

[AdriaandeJongh]

I agree that it makes little sense to give touches a hovering state.

[lyuma]

I just want to offer a rebuttal that there are touch inputs that support hovering.

For example, I plan to use multitouch support for XR finger input, and in XR you have full 6 degree of freedom information about the finger locations at all times when using hand tracking.

Also, tablets with a pen and stylus often show the hover location of the stylus. it's not multi-touch, but it is a form of touch input.

I'm not here to block this on hover support for touch input, just trying to make a case that there are applications (such as my VR framework) that may have a use for hover.

[Kazox61]

Maybe we could add hovering for touch input in a follow up pull request. Currently i don't have a device to test it.

[Alex2782]

Retested on Android: Touch input and Bluetooth mouse.

No critical regressions detected, this PR behaves like version 4.6-official (with input emulation enabled).

I believe a lot more work is needed before proposal #3976 can be closed / before TouchScreenButton can be marked as deprecated.

[m4gr3d]

The code looks good and I wasn't able to detect any regressions from a quick round of testing, so the PR looks good to go!

[m4gr3d]

@Kazox61 Can you squash the commits.

[Repiteo]

Thanks!

[StockerGaming]

Awesome!

[Alex2782]

@Kazox61 Do you still have the motivation and time to fix this issue? #118581
(Otherwise, I'll try my luck, maybe next week)

[shiena]

Hi @Alex2782, I took a shot at this in #118608 — turned out on_action_event() was gating button_down emission on status.hovering, which isn't set on the touch path. Feel free to review whenever convenient.