Unfortuneately I have not the older gir files available, but I think something has changed so that gobject-introspection reports that structures as objects, and in the bindings code it is then processed as gobject with all the toggle_ref stuff. And that is wrong of course.
So the question is, how can we by gobject-introspection differentiate between true gobjects and these objects?
This is not a GObject-introspection change, but a GTK change.
The reason why GskRenderNode and GdkEvent have been restructured to be fundamental types inheriting from GTypeInstance is that they are a the top of a hierarchy of derived classes, and thus cannot be boxed types; they also have immutable instances post-construction, no properties, and no signals, and are meant to be lightweight types, which means GObject is not appropriate for them either.
A fundamental type does not imply a type that does not have a parent; it means it’s a type that is not part of the existing type hierarchy. The “parent” attribute determines if a type has a parent.
Language bindings are supposed to support fundamental types and types inheriting from GTypeInstance, like GParamSpec and all its derived types, like GParamSpecInt, or GParamSpecString, or GParamSpecObject.
seems to return NULL all the time. Well NULL is allowed from the docs, but it is a bit sad. So we have to guess, by scanning all method names for a name containing “unref” or maybe “free”.
[EDIT]
Or to make it more clear: For types like
GskBlendNode, BorderNode, CairoNode
I get always NULL for g-object-info-get-unref-function().
As far as I can see in libgirepository, the ref/unref functions are correctly included in the typelib blob; and if I call g-ir-generate Gsk-4.0.typelib, the regenerated XML contains:
I get the feeling that I have to use parent() to get the RenderNode and then may get the unref function.
So maybe call parent() as long as thre is one in the chain, and then call unref?
[EDIT]
Thanks for your reply, I noticed that myself. RenderNode has the unref function listed, but the chielts not. So my idea to call parent(), but of course there may exist a parent of a parent again, so I have walk upwards until there is no parent any more. It is a bit work, but may work. Thanks.
does not mention that it returns NULL when there is no more parent in the chain. Well we can guess that, but most gtk functions say when they can return NULL, so it would not hurt when get_parent() would tell it too.
OK, it is late here already, will continue tomorrow. Should work all fine.