GStreamer and GIR
Locked
GStreamer and GIR
 
|
The GtkD (D bindings for Gtk) use an automated system that relies on
GIR – I am commenting here from a position of deep ignorance of GIR. Apparently GStreamer has associated GIR files and so the bindings to GStreamer that the GtkD folk create are good, but none of the plugins have GIR files and so all the GStreamer plugin APIs are missing from the D binding – which makes it really annoying to contemplate using D for anything using PlayBin for example. cf. forum.gtkd.org/groups/GtkD/thread/360 -- Russel.=============================================================================Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email] SW11 1EN, UK w: www.russel.org.uk skype: russel_winder _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (188 bytes)
Re: GStreamer and GIR
|
|
Re: GStreamer and GIR
|
|
On Tue, 2016-03-08 at 00:27 -0500, Olivier Crête wrote:
> Hi, > > You don't need gir files to access the plug-ins. They are loaded at > runtime, you access them through the core GStreamer API (GstElement, > GstBin, GstPipeline, etc) and you control their properties using > GObject properties, using g_object_set() in C, I'm not sure how that > was translated into the D bindings. […] But the core issue here is that C is an unsuitable programming language for writing applications. I understand it's use for operating systems (been there done that) and low-level portable libraries (but even here the case is weak). For writing applications however, it is just the wrong tool. Currently the better native code options are C++, D, Rust, Go, maybe Swift, Haskell, OCaml, etc. All of these languages (especially C++ obviously) can use C APIs (it is C linkage for APIs that is crucial here), D, Rust, Go, etc. do though need adapters. These adapter should be generated rather than hand coded. If GIR is not the way forward for GStreamer plugin adapter generation for these other languages, then there ought to be a negotiation about what is the right way forward. Currently both sides of the adapter appear not to be moving on this and the only losers are people who want to write applications in languages such as Rust, Go, Swift rather than C and C++. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[hidden email] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer and GIR
|
|
On Di, 2016-03-08 at 09:42 +0000, Russel Winder wrote:
> These adapter should be generated rather than hand coded. If GIR is not the > way forward for GStreamer plugin adapter generation for these other > languages, then there ought to be a negotiation about what is the right > way forward. 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. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer and GIR
|
|
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. 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? -- Russel.=============================================================================Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email] SW11 1EN, UK w: www.russel.org.uk skype: russel_winder _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer and GIR
|
|
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? 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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer and GIR
|
|
On Tue, 2016-03-08 at 13:56 +0200, Sebastian Dröge wrote:
[…] > 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. Indeed. With the seed sown by Olivier and your contributions in this thread, I am now of the view that the D API as is is as it should be – and that the C++ one should not be as it is. Or at least all that is needed are a few hand-crafted extras to map the C API to something more idiomatic in D. I have reflected this in postings to the GtkD forum. -- Russel.=============================================================================Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net41 Buckmaster Road m: +44 7770 465 077 xmpp: [hidden email] SW11 1EN, UK w: www.russel.org.uk skype: russel_winder _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |