[Bug 702960] gst_element_add_pad()'s pad parameter should be marked as transfer none

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702960
  GStreamer | gstreamer (core) | git

--- Comment #26 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2015-01-08 16:35:27 UTC ---
(In reply to comment #25)
> I just noticed that gi already understands transfer-floating as an alias for
> transfer-none in this case. So imho moving to transfer-floating should be a
> good first step, independent of what the final solution is going to be. It adds
> the needed documentation for C users and has the expected transfer type for
> current bindings.

I thought (transfer floating) did only work for return values, not parameters.
If it works for parameters we should definitely do that.

> Since you were worried (on IRC) about breaking bindings by moving to
> transfer-none. I'd assume all scripting bindings sink_ref atm, and vala seems
> to ref_sink as well, see this small example:
> https://bpaste.net/show/65bdcb07bfff

I assume all current bindings are doing this because otherwise they would run
into problems because GI is not expressive enough, and instead of fixing this
gtk_container_add() and friends became (transfer none).

> I'd also like to add that currently none of the above functions really are
> transfer-floating, as they don't sink the references in case of an error. Imo,
> if you really want proper semantics, this should be fixed as well. This would
> also need further changes as some functions depend on this error-case behavior.

Yes, those need to be fixed to have consistent behaviour on error cases too.
There should be no difference in ownership transfer depending on error or not
in any case.

Want to provide patches? :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.