Allow to unbind AND bind parameters in the signal binding dialog at the same time

[derkork]

Describe the project you are working on

Multiple projects, this one is pretty generic.

Describe the problem or limitation you are having in your project

When using the signal binding dialog, I can either send additional arguments or unbind arguments but not both. In code I can do both, e.g. signal.connect(foo.unbind(1).bind("bar")). However once i set unbind signal arguments to a value > 0, the whole "Add extra call arguments" section is greyed out. This means that for many rather trivial signal connections i have to write an extra method which does the binding/unbinding and then calls the actual target or I have to connect signals in code.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Don't disable the "Add extra call argument" section when "unbind signal arguments" has a value > 0. When both are active create a binding eqivalent to signal.connect(target.unbind(<number of arguments from dialog>).bind(<extra arguments from dialog>).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

See above.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I stumble upon this almost every day, so I figure it would be used often. But yes it can be worked around with a few lines of script.

Is there a reason why this should be core and not an add-on in the asset library?

The dialog is core, so it would need to be added to core.

[MichaelMacha]

I have to admit that this surprised me, and I'm wondering if it might just be an innocent oversight that led to "bind additional arguments" being grayed out. I'm working on a game where I'm permitting stick control but tightly confining a player's movement to a TileMapLayer; and there's a push/pull mechanic. It could be done entirely with signals if I could unbind and then bind; but instead I've had to write utility functions to do the leg work for me.

Additional code is still a problem for me, because it risks bad architecture.

Seems unnecessary.

[Bordraw]

I have run into this as well. I wanted to play a damage animation when my health meter emits a signal, but I have to make my signal have no arguments in order to do this.

[MichaelMacha]

One other thing that might be nice is to have it allow for writing lambda functions. I mean often that can be a bigger problem than a help, but it still tends to beat a full function for a simple method call.

I would like to implement this myself, and would; but I'm having a very hard time understanding what I'm looking at in the C++. Is there a text walk through for how this works anywhere? There are no detailed comments in the code, just function contracts.

UPDATE: Looks like the relevant code might be in _make_or_edit_connection.

[MichaelMacha]

I'm finding multiple cases in the file where unbinds count is verified to be zero before bindings to new parameters are made. Does anyone more experienced with the C++ know the reason for this? I could try editing it out directly, but I think it's important to try and figure out what the writer was meaning to do with it.

Further reading is showing that it's primarily dealing with unbind and bind on Callable. unbind is only called if the number of unbinds is greater than zero; but if (and only if) it is zero, binds are checked. First off, are those quantity checks really necessary, or can it take an empty list harmlessly? Second, why are we only doing the second thing if the first thing is non-applicable?

[MichaelMacha]

From what I'm seeing, it looks like this might be the result of adding a list of new parameters, but only decrementing a number of default ones, and may have just been an oversight on the basis of that. They're handled differently. I'm not sure just yet, though.