gtk-rs / sys

DEPRECATED, each crate has its own sys folder now.
http://gtk-rs.org/
MIT License
30 stars 25 forks source link

gobject_sys::g_signal_handlers_block_matched() unusable? #52

Open hasufell opened 7 years ago

hasufell commented 7 years ago

I see no useful way to invoke gobject_sys::g_signal_handlers_block_matched().

pub fn g_signal_handlers_block_matched(
    instance: *mut GObject,
    mask: GSignalMatchType,
    signal_id: c_uint,
    detail: glib::GQuark,
    closure: *mut GClosure,
    func: gpointer,
    data: gpointer,
) -> c_uint;

The gnome documentation suggest I either need G_SIGNAL_MATCH_CLOSURE, G_SIGNAL_MATCH_FUNC or G_SIGNAL_MATCH_DATA as GSignalMatchType for any match to occur.

I don't see any way to provide either of those information, because of the way the gtk bindings connect to signals, utilizing rust closures I have no access to:

EPashkin commented 7 years ago

You can try G_SIGNAL_MATCH_ID while signal_id acquired by g_signal_lookup

EPashkin commented 7 years ago

Or use glib::signal::signal_handler_block with i64 returned by connect_toggled

hasufell commented 7 years ago

You can try G_SIGNAL_MATCH_ID while signal_id acquired by g_signal_lookup

Doesn't work with g_signal_handlers_block_matches() though:

Passing at least one of the G_SIGNAL_MATCH_CLOSURE, G_SIGNAL_MATCH_FUNC or
G_SIGNAL_MATCH_DATA match flags is required for successful matches.

Or use glib::signal::signal_handler_block with i64 returned by connect_toggled

That's certainly an option right, but g_signal_handlers_block_matches() allows more fine-grained matching, no?

EPashkin commented 7 years ago

Then seems really no way to use this function.