GStreamer and GIR

[Sebastian Dröge]

On Di, 2016-03-08 at 11:52 +0000, Russel Winder wrote:
> On Tue, 2016-03-08 at 13:39 +0200, Sebastian Dröge wrote:
> > 
> > […]
> > Elements (and other things) from plugins are supposed to be used with
> > the generic GObject and GStreamer API. That is, via their signals,
> > properties, etc.
> > 
> > There are wrapper objects for some of them in gstreamer-sharp and
> > gstreamermm, but that's not an ideal solution either as you will have
> > lots of API that might just not work because you're on the wrong
> > platform or just don't have a plugin installed.
> > The ones in gstreamer-sharp are autogenerated btw, not sure about
> > gstreamermm. They are autogenerated from some metadata file generated
> > from the GStreamer registry.
> I would guess that D would follow along similar lines to C++, and I
> guess C#. Given the dynamism involved here (plugins being separate
> downloads, so dynamically found), a strongly typed, explicitly named
> API is not quite such a good idea, I agree with this. So as you say the
> current C++ way of dealing with PlayBin etc. may be far from ideal, or
> indeed possibly wrong. I guess then defining a standard model for C++,
> C# and D to follow would be a good idea?
> 
> I guess this is all leading up to simply exposing the C API with
> strings to do the selection and dealing with error. This would imply
> the highest level abstraction would be Bin and Element? 

But that's what you already should have in all these languages. There
should be API for handling GObject signals and properties for example.

That's basically how the wrappers in the C# bindings are implemented,
they just call those things and provide a strongly typed API for them.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160308/b43765b1/attachment.sig>