Hello, I am using an introspection-based binding within an uncommon language.
I found out that
g_signal_add and similar functions are missing there, likely since these functions are marked “not for language bindings”.
How can I register signals on various language bindings?
Are there alternative functions to register signals intended to be used in language bindings?
I assume you mean
g_signal_newv. The language binding has to include some manually-implemented wrapper code to call those functions. It is hard to say if that exists in a binding without knowing the binding you are referring to.
Sadly, the language binding is purely based on introspection, so I doubt it exists. I guess I should talk to the language binding author to see if this issue could be resolved.
Anyway, thank you!
I strongly doubt that it has no manually-implemented wrappers, that binding would be fairly useless. Connecting signals will not even work that way since
g_signal_connect is also not available to introspection, the bindings need to have a wrapper for
GClosure. Custom signals is similar, the bindings need to have a wrapper for all the gobject and
GType machinery that connects to the class system of the language.
I see, the binding does have functionalities to extend classes and add rudimentary properties. Also GClosure is in the library. That’s about it. I do not know how it managed to introspect signals for existing widgets and add them to the library, but it does not seem to provide a way to add my own signals.
I think when you ask to have the functionality to add your own signals, you actually ask to be able to create new native GObjects and to subclass Widgets in a native way. This is done in C code with C macros, and can be difficult for bindings. Would be useful of course, as then we can create GObjects with our own native Properties, with all the Property-Bindings supported for GObject.
Creating custom signals is sometimes done in plain C code, as it is easily available. I have not seen that be used in non-C code that often, so there may exist ways to do what you want without custom signals maybe. Note, that creating native Widgets from language bindings, that than can be saved as libraries to be used from other languages, is often not possible. For Rust that may work, for other non C languages I am not sure. One solution for your desire may be to write a part of your app in plain C, and call that from your secret other language.
What is “subclassing widgets in a native way”? Is there a language-binding way and native way for extending widgets?
In the binding, I can indeed extend widgets at least.
It depends on the bindings. In OOP languages, subclassing is supported, while plain C as a non OOP languages does not support it. So GObject added some form of its own OOP style to the C language. Some language bindings for languages with OOP support use proxy objects together with the gobject toggleRef() formalism for the bindings. We then can use all the OOP functionality for the proxy objects, so subclassing and automatic memory management works fine, the Widgets behaves like real objects of the OOP language. But as the subclassing is not done the GObject way, creating new GObject properties or GObject signals may not be supported.
If it happens there is already a way to extend widgets using the GObject way, it should not be too hard to add custom signals to the binding. There just needs to be a way to provide some metadata during class construction to use as arguments to
I see, it does not support OOP so inheritance is done by registering class init and instance init functions. E.g. Class init function modifies GObjectClass, is this the native way?
Yes, the signals and propertiers are registered in the class init. You can look at another libgirepository-based binding to see how this is done, e.g. in gjs: GObject.js