GNOME Bugzilla – Bug 638987
[0.11] GstIterator needs a registered type
Last modified: 2017-09-17 10:37:49 UTC
GstIterator should be supported by gobject-introspection, the easiest way of doing it is registering a GType for it. GBoxed would be the most obvious choice but it requires that the size of the GstIterator struct is known to be able to implement the GBoxedCopyFunc properly. That might require ABI and/or API changes. GstMiniObject or GObject are possibilities as well but they will increase the minimum struct size and require ABI changes. Example code with python binding is something like this: it = bin.iterate_sorted() while True: (elem, status) = it.next() if status != Gst.IteratorResult.OK: break # use elem Please note that the above code is merely an example demonstrating how GstIterator access with introspection bindings. Overrides would be needed for convenience and compatibility with gst-python so that you can just iterate over the result directly.
I'm sure there's another GstIterator 0.11 bug already, can't find it now though :( There are many things that should change with GstIterator to be more binding friendly
Created attachment 177828 [details] [review] GstIterator: store size in the struct
Created attachment 177829 [details] [review] GstIterator: free struct in gst_iterator_free
Created attachment 177830 [details] [review] GstIterator: use GSlice
Created attachment 177831 [details] [review] GstIterator: register as a boxed type
To make filter/fold/foreach/find_custom language binding friendly the API would have to change considerably. Something similar to GAsyncResultSet would be needed, python pseudo code: def find_cb(result): element = result.get_object() # do something with element bin.iterate_sorted().foreach(find_cb)
We can add the size and register a boxed type in 0.10 without breaking any API or ABI.
And we should probably use GValue instead of plain pointers for the elements of the iterator. This allows proper reference ownership and bindings can actually know the type of the elements at runtime. Using GAsyncResult for the filter/fold/foreach/find_custom is not a good idea IMHO, it would require to create a GObject for every single call which seems like too much for a simple iterator. Why exactly is this needed at all? How do you handle g_list_foreach() and similar functions in gobject-introspection?
The changes can be found at http://git.collabora.co.uk/?p=user/slomo/gstreamer.git;a=shortlog;h=refs/heads/0.11-iterator It includes all your patches and on top of that an additional commit that refactors GstIterator: http://git.collabora.co.uk/?p=user/slomo/gstreamer.git;a=commit;h=31429220101da25d675dcb6458c483e31902dff0 Any comments on the new API? The latest header can be found here: http://git.collabora.co.uk/?p=user/slomo/gstreamer.git;a=blob;f=gst/gstiterator.h;hb=refs/heads/0.11-iterator Instead of using a GObject* for the owner of gst_iterator_new_list() I think it might make sense to use a GValue* too.
I find using GValues makes everything more painful.
But it prevents scary things like we have right now. For example, in the compare function of gst_iterator_search_custom() you have to unref the item if it's not the one you're looking for and otherwise don't have to unref it. And it makes ownership of references clearer in general and actually allows bindings to use all parts of GstIterator correctly. If you look at my patches to convert the gstbin, the elements, etc to the new API you'll see that the additional code required for GValue in C is minimal.
(In reply to comment #8) > Using GAsyncResult for the filter/fold/foreach/find_custom is not a good idea > IMHO, it would require to create a GObject for every single call which seems > like too much for a simple iterator. Why exactly is this needed at all? How do > you handle g_list_foreach() and similar functions in gobject-introspection? The g_list_* API is not supported directly, but APis using GList can be supported using annotations. If we avoid GAsyncResult we'd just need to annotate the callbacks to know their scope. GValue* makes a lot of sense, perhaps some extra C sugar should be added to hide GValue for the C users, but it doesn't seem to be too bad as you demonstrated. Someone (probably I) need to take a look if gjs/pygobject can handle the patches you sent. Please leave this bug open until it's confirmed that GstIterator can be used properly from at least one dynamic/introspected language binding.
This is now fixed in 0.11, please review the API and check if it works from g-i in some language
So I assume this to be OBSOLETE by now. If not, please reopen.
Not really, none of the bindings people actually reviewed or tested the API AFAIK.
I think the bindings people gave up on this ;)
Oh well, let's close it then
Ok, 5 years later: this is definitely not bindings friendly yet, or at least not GIR-friendly. Took a lot of manual fiddling to get all this mapped to the Rust bindings. Highlight is gst_iterator_filter(), which requires to register some new boxed type to carry the closure around (and it needs to be copyable or with reference counting).