Re: [Gegl-developer] Returning to python-gegl

["Joao S. O. Bueno" <gwidion mpc com br>]

On 12 February 2015 at 16:39, Michael Natterer <mitch gimp org> wrote:
> On Thu, 2015-02-12 at 14:30 -0200, Joao S. O. Bueno wrote:
> > Hi -
> >
> > after several months I am taking back a look at my Python bindings for GEGL,
> > which make use of gobject introspection.
> >
> > The situation with gobject introspection is none but frustrating - maybe
> > one could use it, if he could live in #gobject on irc - but there seens to be
> > no documentation resources wherever.
> >
> > Moreover, it does not work very well,
> > whenever something is not available using the auto-generated bindings,
> > there is no workaround, but to make/request changes on the upstream project
> > and wait for a new release.
> >
> > Add to that things that simply stop working
> > (I just found out I can no longer instantiate a geglBuffer with the gobject
> > introspection - and the solution in my package is a hack already to workaround
> > the constructor failing in the past)
> >
> > Moreover, the latest GEGL stable release is still built with introspection off -
> > so people can't make use of the Python bindings without rebuildoing
> > GEGL themselves,
> > as all distros ship the package without the "gir"  files.
> >
> > But -- I may be wrong --- people may be firmly committed to gobject
> > introspection,
> > and it may be the future, and it is my fault not learning it right -
> > And this is the main motivation for this message:
> > Doo anyone believe/think/can explain/ if gobject introspection has a
> > future at all?
>
> Actually, yes, but I admit I have no clue whatsoever :) People seem
> to be very committed to it.
>
> Without knowing much, proper doc annotations seem to be the key,
> have you checked those?
>
> Also, I think the only way to get real help is #gtk+

Ok, if people are committed to it, that means it is not left
to die, and it is a matter of fixing it in GEGL (and GIMP soon).

I've been looking around, one problem seems to be that since BABL
has no introspection, any functions relying on BABL parameters
(even just babl formats, which are ordinary C strings with
a fancy typedef) are not exported.

  js
 -><-


> --Mitch