Fix mouse dragging in Tree node on touchscreen devices

[syntaxerror247]

Currently, dragging in Tree node is disabled on touchscreen devices and doesn't work even when using a mouse.

This PR enables dragging when a mouse¹ is used.

Footnotes

1. To enable dragging with touch input, I still need to brainstorm a workflow that allows both dragging and touch scrolling to coexist. Normally, apps starts drag-n-drop on long press, but it's currently used to show the context menu. ↩

[Franz-Inc]

I just tested this this PR with my setup (touch-screen Dell XPS with external non-touch-screen monitor) where I used to have the issue (mentioned here: #118938 (comment)) and I can confirm this PR fixes my issue. Thanks!

[AdriaandeJongh]

Just approving this for my colleague @Franz-Inc above; we tested this, confirmed the issue that you cannot drag items in the tree when a touch screen is connected in beta1 and beta2, and confirmed the fix that you can drag with this PR.

Haven't looked at the code.

[deralmas]

Code works, but for some reason there's an annoying bug for people switching between touch and mouse:

Any time you interact with the mouse, the next touch drag will still behave as if it were a real mouse.

This PR as-is improves the situation massively, but this is somewhat annoying. No idea if this is a blocking issue or not. Hopefully it's trivially fixable, although at a glance I'm not sure what's happening.

[Nintorch]

Tested on my Android phone (Redmi Note 11, Android 13). This PR mostly works as expected, I can now drag files in the file system, but, as pointed out by deralmas, the next touch input still behaves as if it were a mouse and drag is enabled, but the next touch input that comes after that behaves as expected (no drag).

Screenrecorder-2026-05-23-10-26-25-367.mp4

To enable dragging with touch input, I still need to brainstorm a workflow that allows both dragging and touch scrolling to coexist. Normally, apps starts drag-n-drop on long press, but it's currently used to show the context menu.

Would it make sense to start dragging on double tap?

[syntaxerror247]

@deralmas @Nintorch Thanks for testing!
Bug when switching between touch and mouse should be resolved now.

To enable dragging with touch input, I still need to brainstorm a workflow that allows both dragging and touch scrolling to coexist. Normally, apps starts drag-n-drop on long press, but it's currently used to show the context menu.

Would it make sense to start dragging on double tap?

No, double tap is currently used to open the file.

[syntaxerror247]

To enable dragging with touch input, I still need to brainstorm a workflow that allows both dragging and touch scrolling to coexist. Normally, apps starts drag-n-drop on long press, but it's currently used to show the context menu.

Would it make sense to start dragging on double tap?

No, double tap is currently used to open the file.

@Nintorch I think you meant double-tap-and-hold drag? yeah this should work. If the user holds the second tap and drags their finger, we start a drag. If they release without dragging, we trigger the normal double-tap behavior (open the file).

I won't be tackling it in this PR, though. I'll experiment with it sometime next month. In the meantime, if anyone wants to test the idea and send a PR, feel free.

[deralmas]

Now works! Changes look fine, with just one nitpick and then it's good IMO.

I have a feeling that, at one point or another, drag_touching was meant to handle all of this, and now got relegated to just whether the feature is on or off. This is all speculation though.

I wanted to do a more consistent analysis of the above but I soon found out that it (and the whole acceleration logic) comes from "GODOT IS OPEN SOURCE" so... The reason this looks so anachronistic is that it is and we should probably look into this separately xD

Nitpick addressed

[Repiteo]

Thanks!