Gst.Iterator should be converted to a generic class just like it was done for GStreamer 0.10. The `user_data` parameter of gst_iterator_find_custom should be a regular parameter (of generic type) and not be treated as closure. A `user_data` parameter doesn't make any sense with GCompareFunc.

Can't we just copy the relevant parts from gstreamer-0.10.metadata to Gst-1.0.metadata?

Was there any progress on this issue? AFAICT, the issue still persists with current master.

Created attachment 250784 [details] [review]
Unhide user_data of Iterator.find_custom

Is it possible to use CompareDataFunc with a [CCode (type = "GCompareFunc")]?

No, this API is pretty weird and the GCompareFunc is not used as such. The func is not called inside "Iterator.find_custom", but wrapped inside a FindCustomFoldData struct and passed to "Iterator.fold".

So GCompareFunc is indirectly used as "int func (void* element, void* user_data)"

http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstiterator.c?h=1.0#n715

I'm thinking we should create an alternate binding for GLib.CompareFunc (SearchFunc maybe?) which takes two type parameters, and use that here.  Something along the lines of:


[CCode (cname = "GCompareFunc", has_target = false)]
public delegate int SearchFunc<A,B> (A a, B b);

public class Iterator {
  [CCode (simple_generics = true)]
  public bool find_custom<T> (CompareFunc<GLib.Value?,T> func, out GLib.Value elem, T user_data);
}


I'd have to look at the source, but maybe elem should be unowned?  The documentation isn't really clear.

(In reply to comment #7)
> I'm thinking we should create an alternate binding for GLib.CompareFunc
> (SearchFunc maybe?) which takes two type parameters, and use that here. 
> Something along the lines of:
> 
> 
> [CCode (cname = "GCompareFunc", has_target = false)]
> public delegate int SearchFunc<A,B> (A a, B b);
> 
> public class Iterator {
>   [CCode (simple_generics = true)]
>   public bool find_custom<T> (CompareFunc<GLib.Value?,T> func, out GLib.Value
> elem, T user_data);
> }
> 
> 
> I'd have to look at the source, but maybe elem should be unowned?  The
> documentation isn't really clear.

Wouldn't something like:

[CCode (cname = "GCompareFunc")]
public delegate int SearchFunc<A> (A a);

public class Iterator {
  public bool find_custom ([CCode (target_pos = -1)] SearchFunc<GLib.Value?> func, out GLib.Value elem);
}

Make more sense?

Yes that's interesting as well as it allows for the use of closures. I'm for it as long as Evan and Rico don't find any problem.

Created attachment 251616 [details] [review]
Fix Iterator.find_custom

I can confirm that the patch in comment 10 fixes this issue. I would highly appreciate if this patch could be committed to master and be part of the next release.

(In reply to comment #11)
> I can confirm that the patch in comment 10 fixes this issue. I would highly
> appreciate if this patch could be committed to master and be part of the next
> release.

I'm more interested in comment #8, would that work for you?

Sebastian, rev 6296d34707d0053919d9496b5cf6c50149fea702 has a hunk with regards to this. Does this already fix the problem or there still something to do?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/321.