4.3
The LineEdit control has a signal for when the user changes the text value “text_changed”
This signal is called whenever the user types anything, so connecting a callback to that signal would theoretically be costly.
Is there a functionality I’m missing which waits until the user has stopped typing before emitting a signal with the final text value of the control? Or is that a customization I’ll need to implement.
There’s no built in signal to detect when the user has stopped typing. There is text_submitted though which requires the user to press enter though. If you want to detect if the user has stopped typing, you could start a timer with a function connected to the text_changed signal and only run your logic for the text when the timer times out.
Personally I don’t think I’d worry too much about too many text_changed signals; even if the player is absolutely spamming the keyboard they’ll still have trouble generating more than one signal per frame unless you’re running under 15fps. People just can’t type that fast, and Godot (and any other game engine, really…) can handle per-frame updates on other input sources just fine.
If you’re doing something expensive in response to the signal (like, really expensive, spawning something complex maybe?) then @paintsimmon 's timer scheme would handle it. Maybe something like:
# Note: untested, scribbled pseudocode; important stuff may be missing/wrong...
const TEXTCH_TIME = 10.0 # 10 seconds
@onready var text_changed_timer = SceneTree.create_timer()
var text_changed_ready: bool = true
func handle_text_changed(...):
if text_changed_ready:
text_changed_ready = false
do_stuff()
text_changed_timer.time_left = TEXTCH_TIME
# stop/restart timer if needed...
func handle_textch_timer_timeout():
text_changed_ready = true
Yeah I considered that, but I wanted to see what other people may suggest as well in case I might’ve missed something.
Thank you for the input.
Indeed it would be a solution.
Thing is, the issue I’m facing isn’t because of godot’s limitations as much as it is derived from my lack of knowledge regarding signal costs.
I’m not doing anything heavy honestly, and given the software that can be made in godot, what I want to achieve is negligeable in hindsight, just an update to a dictionary that’s a few classes and function calls away, given the structure of what I’m building.
It’s just that it seemed too much to trigger a signal and do all of what I want to do on every. single. letter. that the user types.
But yeah, I doubt it’ll be too much, will do some testing and see what comes out of it.
Thanks for the input
It can be counterintuitive, but from the computer’s point of view, the player is reeeally sloooow. The computer can do a lot while waiting for player input.
The computer also has no idea when the user has stopped typing.
Even using the timer system is just guessing.
For example it can’t know that a letter is typed and the user interrupted before finishing,
If I am entering text into a textbox, I expect that control to wait for me to press enter (submit).
I’m using editing_toggled signal in my project to detect when the user has exited the field - and only then run the appropriate update logic. It’s better than text_submitted, as it doesn’t require enter to be pressed. Just make sure to check for the toggled_on == false condition before you run your logic, otherwise you’d be updating on the entry as well.
I agree with the previous colleagues though - you shouldn’t need to worry about optimising around player inputs unless you see your code struggling.
Thanks exactly it! 
Thank you very much.
Amendment: I didn’t see it because the version of godot I’m using doesn’t have it 
Oh well