Add a way to debounce signal handler

[timothyqiu]

Inspired by godotengine/godot#99812, I believe debouncing is a common requirement for controls that accept user input.

We can provide a special Callable that calls the wrapped child Callable in a debounced manner.

# Callable.debounced(seconds: float) -> DebouncedCallable
line_edit.text_changed.connect(_some_handler.debounced(0.5))

I am not familiar with the implementation of Callable. How to obtain the time may require further design.

[sockeye-d]

I made this:

func debounced(fn: Callable, debounce_sec: float) -> Callable:
	# is array because they are passed by reference
	# (it's hacky, I know)
	var last_call_usec: PackedInt64Array = [-1.0]
	return func():
		if last_call_usec[0] == -1.0 or (Time.get_ticks_usec() - last_call_usec[0]) * 1e-6 > debounce_sec:
			last_call_usec[0] = Time.get_ticks_usec()
			fn.call()

It's kind of goofy but it seems to work

[Calinou]

This could also be provided for throttling, but debouncing is arguably needed more often in UI interactions.

[adamscott]

@dalexeev What do you think? I think you're one of the most knowledgeable person I know about Callable, if I'm not mistaken.

[dalexeev]

Technically this can be done with a CustomCallable. The question is whether we should support it out of the box, given that users can implement it themselves with SceneTreeTimer/Tween. Also, how much can the required behavior vary? Is there a single option that will satisfy all users?

[timothyqiu]

@dalexeev The point of this proposal is indeed to reduce the user's boilerplate code.

ReactiveX established an API for debouncing that seems to satisfy all users.

[adamscott]

I think it could greatly improve UX inside the editor as well.

[passivestar]

If godot provides signal debouncing/throttling on the engine level shouldn't it be done in a way that's compatible with persisting connections so that it can be serialized and edited through the editor UI, just like one-shot and deferred?