Re: mm-projects and gobject-introspection
- From: Murray Cumming <murrayc murrayc com>
- To: Marcin Kolny <marcin kolny gmail com>
- Cc: Daniel Elstner <daniel kitta googlemail com>, gtkmm-list <gtkmm-list gnome org>
- Subject: Re: mm-projects and gobject-introspection
- Date: Thu, 02 Oct 2014 22:03:46 +0200
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 kolny 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
<juanrgar 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 ahlstedt 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 kolny 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
murrayc murrayc com
www.murrayc.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
