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
<mailto: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
