One more question (for maintainers, I think); should I keep my code on a git.gnome.org server in separated branch or somewhere else, e.g. on my github?
2014-10-01 10:50 GMT+02:00 Marcin Kolny <marcin.ko...@gmail.com>: > 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 > -- Pozdrawiam Marcin Kolny
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
