I wasn't aware of that branch. We should start from there, or borrow some code. Thank you!
Best regards, Juan. On Wed, Oct 1, 2014 at 10:16 AM, Kjell Ahlstedt <kjell.ahlst...@bredband.net > wrote: > Have you seen glibmm's gmmproc-refactor branch in the git repository ( > https://git.gnome.org/browse/glibmm/?h=gmmproc-refactor)? Krzesimir Nowak > has started a complete rewrite of gmmproc, using gobject-introspection, I > think. Nothing has been added to that branch since July 2012. Still, it > might be worth looking at. Sorry, I don't know anything about it, except > that it exists. > > Kjell > > Den 2014-10-01 08:22, Juan Rafael García Blanco skrev: > > 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
