Gst 1.18, gst_structure_from_string() and introspection

I had some trouble with it, see

It is indeed only this one single function currently, but the general issue is about the parameter list of constructors.

Until gst 1.16 gst_structure_from_string() was a plain function, and we had no problems.

But since recent version gst 1.18 it is a constructor. And a constructor with out parameter. That is very uncommon, and not handled well from my gobject-introspection code.

      <constructor name="from_string" c:identifier="gst_structure_from_string">
        <doc xml:space="preserve"
             line="2312">Creates a #GstStructure from a string representation.
If end is not %NULL, a pointer to the place inside the given string
where parsing ended will be returned.

Free-function: gst_structure_free</doc>
        <source-position filename="../gst/gststructure.h" line="335"/>
        <return-value transfer-ownership="full" nullable="1">
          <doc xml:space="preserve"
               line="2323">a new #GstStructure or %NULL
    when the string could not be parsed. Free with
    gst_structure_free() after use.</doc>
          <type name="Structure" c:type="GstStructure*"/>
          <parameter name="string" transfer-ownership="none">
            <doc xml:space="preserve"
                 line="2314">a string representation of a #GstStructure.</doc>
            <type name="utf8" c:type="const gchar*"/>
          <parameter name="end"
            <doc xml:space="preserve"
                 line="2315">pointer to store the end of the string in.</doc>
            <type name="utf8" c:type="gchar**"/>

So the main question is: Is this shape of constructor an exception, and I can just ignore (skip) it for automatic binding generation, and add manually bindings code when needed? Or is this the new upcoming constructor shape and I have to handle that types of constructors automatically? The later is not easy, and testing is difficult too with only one use case. But well we have code that handle these parameter lists for functions, so we may try the same for constructors when really necessary.

This is caused by this commit.

I don’t know if that’s correct or not, in gobject-introspection terms, but a constructor with out parameters also doesn’t seem very strange either.

Note that the out parameter is marked as skip so bindings would usually skip over it so it should be even less of a problem.

@ebassi What would you say, is this wrong usage of gobject-introspection or should the Nim bindings just handle it?

1 Like

The function should probably not be marked as a constructor, but as a static function.

We had a similar API in GDK, with gdk_color_parse(), but we replaced it with the more idiomatic gdk_rgba_parse(), which modifies the passed instance argument.


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