Hi guys, Thanks for your reply. Of course, I know that we cannot use typelibs, and actually I just wanted, as a first step, parse gir files and generate .defs.
gmmproc-refactor branch will be very useful for me, but I'm afraid, that I can't just continue this branch because of lot of changes meanwhile (yeah, it's 2 years). But I'm pretty sure, that Krzesimir's commits will be very useful for me, I have to study this branch before start my work. 2014-10-01 10:30 GMT+02:00 Juan Rafael García Blanco <juanr...@gmail.com>: > 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 >>> >>> _______________________________________________ >>> >> >> > -- Pozdrawiam Marcin Kolny
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
