GNOME Bugzilla – Bug 584269
Enhance decodebin bindings
Last modified: 2009-09-11 08:51:03 UTC
The second argument of the new-decoded-pad signal, islast, is deprecated [1] and probably not of much use for the managed world anyway. --- a/gstreamer-sharp/baseplugins/decodebin.metadata +++ b/gstreamer-sharp/baseplugins/decodebin.metadata @@ -2,4 +2,4 @@ <metadata> <attr path="/element/element-signals/signal/name[child::text()='new-decoded-pad']/../params/type[1]" name="name">Pad</attr> - <attr path="/element/element-signals/signal/name[child::text()='new-decoded-pad']/../params/type[2]" name="name">Last</attr> + <remove-node path="/element/element-signals/signal/name[child::text()='new-decoded-pad']/../params/type[2]" /> <attr path="/element/element-signals/signal/name[child::text()='removed-decoded-pad']/../params/type[1]" name="name">Pad</attr> With the seconds argument removed, NewDecodedPadArgs and RemovedDecodedPadArgs now have the same signature. Wouldn't it make more sense to simply have a DecodedPadArgs and DecodedPadHandler shared for both signals? The same would go for FakeSink.Handoff, FakeSink.PrerollHandof, FakeSrc.Handoff and Identity.Handoff. They all share the same signature and semantics, so the cleanest api would be for those shared Args/Handlers to live in the Gst.CorePlugins or Gst.BasePlugins namespace as normal classes. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-decodebin.html#GstDecodeBin-new-decoded-pad
(In reply to comment #0) > The second argument of the new-decoded-pad signal, islast, is deprecated [1] > and probably not of much use for the managed world anyway. > [...] Right, I'll apply that patch. The parameter would still be useful in managed world but the no-more-pads signal of GstElement is the better indicator. > With the seconds argument removed, NewDecodedPadArgs and RemovedDecodedPadArgs > now have the same signature. Wouldn't it make more sense to simply have a > DecodedPadArgs and DecodedPadHandler shared for both signals? > > The same would go for FakeSink.Handoff, FakeSink.PrerollHandof, FakeSrc.Handoff > and Identity.Handoff. They all share the same signature and semantics, so the > cleanest api would be for those shared Args/Handlers to live in the > Gst.CorePlugins or Gst.BasePlugins namespace as normal classes. That would be perfect, yes... but it would either complicate the element bindings generator or require custom code. What's the advantage of having the same delegate/signal type for both?
commit 0f55df8e256364604ce1f402f2e6fa016706f0ba Author: Maarten Bosmans <mkbosmans@gmail.com> Date: Sat May 30 13:38:01 2009 +0200 Remove the Last parameter of the new-decoded-pad signal of decodebin That parameter was deprecated and the no-more-pads signal is a much better indicator for this. Fixes bug #584269. I'll close this bug, if you think having the same delegate/signal args type for multiple signals is useful and worth the additional effort please open a new bug for this :)