Gst 1.18 gst_structure_take() and introspection

Platform Language bindings
1

I added gstreamer to the Nim GTK bindings once because someone asked for it, but he never came back :frowning:

Indeed gstreamer is not that easy for gobject-introspection.

gst_structure_take() does currently not work for the Nim bindings, I guess the problem is that first parameter is a pointer to pointer (**) that can be NULL. Have never seen that for the other GTK bindings. For Nim we generally make parameters of type ** var ptr, as we have var parameters as known from Pascal. But var parameters can not be NULL.

Well I think I will make the bindings just ignore these function, then it compiles again.

But I still wonder: Makes passing NULL for the first parameter makes sense at all?

https://gstreamer.freedesktop.org/documentation/gstreamer/gststructure.html?gi-language=c#gst_structure_take

2

oldstr_ptr cannot be NULL. It’s oldstr that can be NULL. The first argument always must point to a variable. That variable may contain the value NULL.

1 Like
3

@greg-king

OK. For me it is still hard to understand the API doc.

https://gstreamer.freedesktop.org/documentation/gstreamer/gststructure.html?gi-language=c#gst_structure_take

Either newstr and the value pointed to by oldstr_ptr may be NULL

Either in conjunction with and? Have not seen this that often. And

oldstr_ptr ( [inout] [transfer: full] [nullable] )

Is nullable not indicating that oldstr_ptr itself can be NULL.

Well I will make this function skip for now, it is too hard for me currently.

4

Is there already some progress?

From my previous post the core message was that I assume that the nullable tag is wrong. I compared with some other GTK functions which seems to support my feelings.

But maybe I am still wrong, in that case I would have to modify the code which generates the bindings. In latest version 0.8.2 I just skip this function.

5

I think that’s the correct approach here. This is really just C API, I’m sure Nim already has something better than that. It’s similar to g_clear_object(), gst_object_replace(), etc.

What was the use-case someone was asking for it in Nim?

Not really, I never saw it used like that and wouldn’t know why one would want that :slight_smile:

nullable T** pointers nonetheless make sense and I’m sure you already handle that in other cases for optional out parameters and GError **.

1 Like
6

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