Expose gobject_sys::g_signal_stop_emission

[Susurrus]

My understanding is that functions in the *_sys modules should not be used in favor of them being exposed in safe Rusty APIs. I'd like to use gobject_sys::g_signal_stop_emission and a module allowing its safe use would be useful.

For context in case I should be going about this a different way, is that I'm trying to override the default signal handler for insert-text for a TextBuffer so that I can not render the characters in the entry field but still process them within my program.

[GuillaumeGomez]

cc @gkoz

[Susurrus]

Is this a simple operation, involving copy/paste plus a little modification? If so, I could possibly do this work, though I'm definitely a Rust newbie.

[gkoz]

This will take a trifle of design work but should be doable without much experience, mostly you'll need to 'get' how the bindings use the translate module and possibly take a peek at libgobject source.

[Susurrus]

@gkoz Were you thinking of looking into this over the next week or so? If so, I think it'd be best to leave it to you. Otherwise I can try to take a stab at it though I'm betting I'm going to be needing some hand-holding to get through it. I just don't want to go down that road if you guys would see it more of a burden than a benefit (which is understandable, we're all busy).

[gkoz]

@Susurrus nah, I wasn't. Take a stab at it, it's more fun when more people look into the insides of GTK ;)

[Susurrus]

Okay, I've started digging into this a little bit, and I got gir compiling and think I'm ready to start stuff. But here's the question, where should these functions go (list here)? They're in the glib-object.h header, logically listed in the docs as gobject/signals. I think this function should be glib::signal::stop_emission_by_name and put in the manually-created file src/signal.rs, does that sound right?

[EPashkin]

Yes, g_signal_connect_data as connect already there.

[gkoz]

I don't think gir will be of help here because it doesn't generate free functions in the high-level crates. Placement in mod signal is correct.

[Susurrus]

I'm getting pretty confused with the organization of this project, so I'd like to clarify some more here. I see that there is a separate glib project. Both glib and gtk have signal modules and it's not clear to me which functions should go in which modules. For example, destroy_closure() is actually implemented in both modules, which seems incorrect to me. Also connect() is implemented in glib only which idle_add() and friends are implemented in gtk. Can someone clarify where I should be adding a stop_emission() function, in glib or in gtk? I would think even the idle_add() functions and friends should be in glib, which is why I'm confused.

[gkoz]

libglib and libgobject stuff goes into the glib crate as outlined in its synopsis, that would place signal utilities into glib::signal.. Closures handling evolves gradually hence little inconsistencies likedestroy_closure and connect. idle_add duplication is documented but perhaps not clearly enough?l

[Susurrus]

I've started work on this in the glib library for the g_signal_override_class_handler() lease see gtk-rs/glib#127, which I think is actually what I want actually. I'll add stop_emission once I get that PR sorted out.

[gkoz]

stop_emission feels like a more realistic target right now because it doesn't need to be aware of each signal's signature.

[Susurrus]

This should be done as of gtk-rs/glib@7ff176b, but I don't know how glib gets included in gtk, I think it's exposed through gtk as well, so I think this can be closed.

[gkoz]

We don't reexport glib in gtk so you'll have to import it in your project. And yes I believe this can be closed.