Re: mm-projects and gobject-introspection

[Juan Rafael García Blanco <juanrgar gmail com>]

Hi,

I did try to generate C++ bindings for gobject-introspected libraries. However, all I achieved before losing interest was a gir parser written in python (you can see advertisement of this in the list's archives).

I don't understand what you mean by 'why don't we use it in mm projects instead of writing perl scripts'. gobject-introspection provides two products for each library: a XML file (gir) containing the definition of the API, and a typelib where that definition is compiled (platform dependent). For mm projects the gir files could be really useful, and we could replace the current set of perl scripts with a set of programs/scripts that parse the gir files and generate the .defs files from them. But you cannot avoid writing something to parse the XML gir files; note that typelibs are platform dependent and therefore are not suitable for our needs.

In my opinion, and I think in the opinion also of more people, a first step would be to generate the .defs files from gir files, writing a parser in perl, python, ... whatever.

A second step could be to, in addition to .defs files, generate also the .hg and .ccg files from gir files. I think this needs to add some flexibility for inserting hand-written code, since APIs are not always that good and we may want to make modifications, event to make them more C++-ish.

So, conclusion: mm projects could take advantage of gobject-introspection for generating .defs files and even .hg and .ccg files. We shouldn't, however, replace all that has been done and come up with new API conventions; i.e. we shouldn't get rid of RefPtr, GLib::Object, ... However, gobject-introspection is not a panacea: in contrast with what happens with interpreted languages, we still need to provide separate packages for every wrapped library, i.e. we obviously cannot provide dynamic bindings using typelibs.

As far as I know, someone wrote a Go bindings generator from gobject-introspection; and also for Java.

I recently created a project on github (it is empty nowadays) to write a gir parser that can output .hg and .ccg files. This could be useful for wrapping, for example, new classes. Instead of writing a bunch of WRAP_METHOD/PROPERTY/SIGNAL statements by hand, that could be easily automated from gir files. Therefore, if you decide you want to go with gobject-introspection, please do not hesitate to contact me if you need help :)

Best regards,

Juan.

On Wed, Oct 1, 2014 at 1:10 AM, Marcin Kolny <marcin kolny gmail com> wrote:

Hi everyone,
I recently have talked with guys in #gstreamer irc channel, and they told me about gobject-introspection. I've heard about it earlier, but I've never interested about it, I even didn't know, what is a goal of this project, who should use it.
I spent a some time for reading about gobject-introspection, and now I'm wondering, why don't we use it in mm project instead of writing perl scripts, which actually not working in all cases.
Have somebody ever taken care about usage gobject-introspection in mm projects? If there is someone with experiences, could he share it with me?
Or maybe there is a serious reason to NOT use gobject-introspection in glibmm/gtkmm/gstreamermm/(other)-mm projects? Please tell me about it!

If there is no objection, to start using gobject-introspection, I'm ready for spending next few months for doing some researches, and e.g. porting glibmm project. But I need your opinion. Just tell me: "yeah, that's what we're waiting for! Go ahead" or "Don't waste your time, because..."
Especially, I'm counting on a mm active developers/maintainers, but everyone's opinion is very important for me.

--
Best regards,
Marcin Kolny

_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
https://mail.gnome.org/mailman/listinfo/gtkmm-list