Add a way to propagate signals instead of having to emit a new signal from a handle

[sylbeth]

I'd like to have a way to propagate a signal without needing to write a handler for it. Sometimes, you just need a node to reinterpret a signal as one of their own signals, and that's it. I believe this would lead to performance improvements (albeit quite low) and reduce code clutter, also making it extremely easy to propagate them. I'd give another method instead of connect, being reemit, or something, and thus when receiving the signal reemiting it exactly the same under some other name. node.signal.reemit(node2.signal) could be a good way to do it, and also to give the option to do it from the editor.

[sockeye-d]

You can already do

node.hidden_signal.connect(new_signal.emit)

[sylbeth]

OH, yeah, I was being kind of dumb, and I'm the one that always does this kind of thing instead of making closures in Rust, ha, funny. Thank you very much!

[sylbeth]

It is true that it can be done through code, but not in the editor. I can't connect those two together because it's not a valid identifier. Can there be something done about it?

[AThousandShips]

See also:

• Add a method to connect a signal to another signal emission #9458

[sylbeth]

is it an unusual case to reemit a signal? I believe it's one of the recommended code practices for dealing with scenes

[AThousandShips]

No it's unusual to just connect one signal to another and do nothing more at all, so adding a lot of additional functionality to the editor would need some more cases to justify, especially if pre-bidning is implemented and it becomes trivial to do this with just emit_signal.prebind("signal_name")

[sylbeth]

Alright, then what about being able to connect to autoload/singleton receiver methods? I keep having to do that through code.

But that's much more machinery than allowing methods and reemitted signals. How would you go about making a volume slider scene? One that's a mute checkbutton and a horizontal slider. In such case, you only want to tell the main scene when volume changes, which is simply reemitting, and when the button is pressed, again, reemitting. Sure, you could handle the volume changing in the slider by providing an audio bus as an export variable, but this is just one such case.

[AThousandShips]

But that case can be trivially solved with minimal code, but again for re-emitting the solution doesn't require changes to this part of the engine, but instead just adding pre-binding, or already just adding a custom method for this that uses vararg etc., but if it's not strictly about re-emitting signals it's out of scope for this

But there always needs to be a balance between things, adding a lot of additional functionality to make something possible strictly with the connections menu when it can be done with two lines of code is IMO very unreasonable, it also makes it a lot harder to adjust your code, what if you want to debug the code and add a print directive to the callback, or if you want to extend it by, for example, control some volume sliders from other ones, etc., etc.

I'd say the connection menu and the binds system for scene files is meant as a very minimal system and most complex cases should simply be handled in code, and that the cost of writing boilerplate code to do it is reasonable in comparison with a lot of extra functionality that would have to be added not just in the editor but in core, in the way scene files and code works

It also opens up weird edge cases where connecting to a variable to a node can break if the variable is reset, or initialized differently, etc.

[sylbeth]

Pre binding and using emit signal makes you use the names of the signals and gives you no compilation guarantees whatsoever, though, right?

But yes, if it is so much more machinery with weird edge cases, then that's where the proposal ends.