Re: Passing a GObjectClass into a function (with GooCanvas2)



On 03.10.2017 00:46, Zakariyya Mughal wrote:
I think it has to do with a possible bug in the GooCanvas annotations
where they specify the return type of `GParamSpec**` as having
`(element-type GObject.ParamSpec)` despite the return type not using a
container type like `GSList*`. To compare, see:

- `goo_canvas_item_class_list_child_properties` 
<https://git.gnome.org/browse/goocanvas/tree/src/goocanvasitem.c?id=cd1ad0f66ded84901f77519434191ae108dadace#n2377>

- `goo_canvas_item_model_class_list_child_properties` 
<https://git.gnome.org/browse/goocanvas/tree/src/goocanvasitemmodel.c?id=cd1ad0f66ded84901f77519434191ae108dadace#n1155>

I recompiled GooCanvas without the `element-type` annotation on
`goo_canvas_item_model_class_list_child_properties` and the error
goes away. Perhaps the semantics of using `element-type` need to be
restricted or clarified?

Yes, the annotation seems to be incorrect.  It makes
gobject-introspection think that the returned value is a flat array of
GParamSpec structs, while in fact it is an array of pointers to
GParamSpec structs.  In the *.gir file, the difference is:

  <type name="GObject.ParamSpec"/>

versus

  <type name="GObject.ParamSpec" c:type="GParamSpec*"/>

Can you bring this to the attention of the GooCanvas developers?

While you're at it, please also mention that the ownership annotation
for the return value of goo_canvas_item_class_list_child_properties
seems to be incorrect.  It currently says "transfer full" (which means
the array elements and the array itself can be freed), but the
implementation suggests that "transfer container" would be correct.
(goo_canvas_item_model_class_list_child_properties gets this right.)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]