G_signal_connect and variants are not introspected

Hi,

it seems that g_signal_connect (a C macro), g_signal_connect_data and g_signal_connect_object are not available for introspection. Looking at the parameters, I can understand that it might be difficult (though not impossible) to write marshalling code for _connect, _connect_data and _connect_object.
But it doesn’t seem to be a good reason anyway.

I’m building bindings for my own interpreted language, and I’ve checked in PyGObject. Only g_signal_connect_closure is available.

I’d like to understand the rational behind it.
Thamks,
David

Macros are not introspectable, of course: they are C pre-processor entities, and cannot be used from non-C languages.

Language bindings should provide their own convenience wrappers around g_signal_connect_closure() instead.

Of course macros are not introspectable. But the question was for g_signal_connect_data.
From the header files, it seems to be a regular function like g_signal_connect_closure.

The introspection scanner marks it as not introspectable, likely because it has two callbacks and the lifetime of the data is tied to the GDestroyNotify function, but not to the callback itself. The solution is to use the connect_closure() variant, which makes the memory management of the data attached to a signal obvious and automatic.

In practice, most languages using introspection data at run time (as opposed to code generators consuming th XML) ignore these functions because they have native bindings for GLib and GObject API, including signals, and don’t use the GObject API through introspection. GLib and GObject predate introspection, and so do most language bindings that have been ported to use introspection. You may consider having a native wrapper for GObject part of the bootstrapping process for a new language binding.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.