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.ko...@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 > >
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
