Add a way to connect to signals with after=true

[sdroege]

See g_signal_connect() vs. g_signal_connect_after() in C. We can already do that via ObjectExt::connect() but it would be useful to also have this for the strongly typed signal connection functions.

Any ideas? @EPashkin @GuillaumeGomez ? :)

[EPashkin]

IMHO currently it not necessary

[sdroege]

What do you mean with not necessary? :) It's needed for correct usage of some APIs.

[EPashkin]

Example please, that we can't cover with bool parameter

[sdroege]

We don't have a bool parameter, that's the problem exactly :)

[sdroege]

Also, basically all GTK signals that return Inhibit. You might want to connect to them and have your callback called after the default handling is all done already (and e.g. the togglebutton decided if it can toggle or not, if a previous handler returned Inhibit(true) you wouldn't be called anymore, etc).

[EPashkin]

Seems I don't understand question, as we have flag in ObjectExt::connect https://github.com/gtk-rs/glib/blob/ff2e05f017761c751b13cb92a31a027e6397370d/src/object.rs#L1301

[sdroege]

Yes that's the dynamic one with glib::Values everywhere. That's not very nice to use. ButtonExt::connect_clicked for example has no way to connect after.

[EPashkin]

You want to add ButtonExt::connect_clicked_after ?
Always or only on config flag?

[sdroege]

That's exactly the question, how to handle that best :)

[sdroege]

So options I can think of (either always or configurable / opt-in):

• Add a bool parameter to them (breaks existing code)
• Add a connect_after_XXX variant (adds lots of new functions that are basically the same)

[EPashkin]

In public interface I prefer connect_after_xxx

[sdroege]

That would mean to duplicate the trampoline though (it's inline inside the connect function).

If we go that way we should probably also make it connect() and connect_after() on ObjectExt for consistency.

[EPashkin]

IMHO changing ObjectExt is not needed

[sdroege]

IMHO changing ObjectExt is not needed

Well, it would be more consistent :)

@GuillaumeGomez do you have any opinions?

[GuillaumeGomez]

Not really. :-/

[sdroege]

Then I'd go with connect_XXX and connect_after_XXX for everything, and also do the same for ObjectExt::connect (i.e. add an connect_after there instead of the boolean parameter).

But before doing so I'd wait for @GuillaumeGomez to finish his work on converting the signal handlers to glib::Closures as that's going to touch the same code.

[GuillaumeGomez]

Oh, considering my current motivation, it might take a while. :-/

[sdroege]

We could maybe make use of const generics here:

pub fn connect_foo<const A: bool, F: Fn()>(&self, func: F) { ... }

However there does not seem to be any syntax to define a default value for const generics (const A: bool = false or something like that)? Without that would become rather annoying to use for the normal case as it would always have to be provided.