Please use git.gnome.org. Feel free to create a branch of glibmm or gtkmm or whatever if it helps.
Murray On Thu, 2014-10-02 at 18:21 +0200, Marcin Kolny wrote: > 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 -- Murray Cumming murr...@murrayc.com www.murrayc.com _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
