GNOME Bugzilla – Bug 710407
caps: Add GI friendly variants of make_writable () and copy()
Last modified: 2018-11-03 12:18:59 UTC
Looks like the Rename to: annotation does not work in this case as the other variant is not introspected at all, what do you suggest? Another question is, couldn't we make those function not inlined?
Created attachment 257583 [details] [review] caps: Add GI friendly variants of make_writable () and copy()
The problem here is just that GI does currently not support inheritance on non-GObject types. I think that's what should be fixed here instead of working around GI bugs on our side. The subclass wrapper functions for GstMiniObject functions are only C convenience functions really. (Of course we could just change the inline functions to real functions, that's not breaking anything... and would be better than adding _gi variants. But I still think that it should be fixed in GI instead)
About the copy method, we can not actually fix that in GI as there already is a gboxed.copy() method which actually refs the caps instead of actually calling the copy method, we need a variant method, at least for that. unless you see another option? :) And I do agree with you we should be able to tell GI that the method from the X box type can be applied on Y.
The copy thing is IMHO also something that should be fixed in GI. Maybe GstMiniObject should not be handled as "boxed type" in GI but as a new type. A "manual" type or something... where you can define via annotations how to ref/unref it, how the type hierarchy is, etc. Something that could also handle plain C types with old school C inheritance.
Right, sure, I would say "let's be realistic" and try to fix that problem now, because even if I do totally agree about what you said I do not see that happening soon, and GstMiniObject is a boxed type in 1.0. Currently the only option we have to copy caps is doing Gst.Caps.new_from_string(caps.to_string()); not real great! I will attach paches that make those functions not inline, in case by chance you agree about merging that :)
Created attachment 257593 [details] [review] caps: Make make_writable () and copy() not inlined So they can be used with instrospection bindings.
How does that help with copy() not being accessible via GI though? I wouldn't like to add ugly _gi variants of these functions, with un-inlining them I'm ok but we should ask others too
That works, PyGObject calls our version of the caps.copy() method and not boxed.copy(), not sure about other bindings.
I think this is something that g-i people should confirm, that all bindings should be handling it like this. we don't want to find out that it's not intentional and then everything breaks later because it's changed in bindings. And is our writability as a concept usable from bindings at all (in general, not by accident)?
(In reply to comment #9) > I think this is something that g-i people should confirm, that all bindings > should be handling it like this. we don't want to find out that it's not > intentional and then everything breaks later because it's changed in bindings. I do not know who we should ask, but yes I agree we should make sure that this behaviour is intentional. > And is our writability as a concept usable from bindings at all (in general, > not by accident)? We need to make sure it is usable as we do need to be able to know whether the caps/structure we are working with are writable or no, even from bindings.
Did anybody ask the g-i / pygi bindings people already? Best would be to check the maintainers of those and ask them, or check on #gnome-hackers or #introspection on gimpnet
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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.freedesktop.org/gstreamer/gstreamer/issues/44.