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?

Otherwise, I think I will rewire the python bindings using another method to bridge to the C library, which is more predictive and better supported. (I also accept suggestions for that - since I prefer working in Python itself, my options would be ctypes or cython)

js ->

So it looks like the right-thing-to-do now is to add introspection to Babl (otherwise we will need dirty workarounds in gegl).

js -> wrote:

On 12 February 2015 at 16:30, Joao S. O. Bueno wrote:

Otherwise, I think I will rewire the python bindings using another method to bridge to the C library, which is more predictive and better supported.

I've made a Python binding for my largish C library using gobject-introspection and not had any serious problems. It was a bit wonky a year or so ago, but it honestly seems OK now. Performance is good too, and I don't see any memory leaks. I'm very grateful for it.

I've been trying to make a Ruby binding in the same way and oh dear oh dear it's a lot harder :(

John

On 12 February 2015 at 16:39, Michael Natterer 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

On 13 February 2015 at 20:12, Jon Nordby wrote:

On 13 February 2015 at 01:52, Joao S. O. Bueno

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.

Daniel Sabo fixed this a good while back, by writing simple wrappers with introspectable type signatures:
https://github.com/GNOME/gegl/blob/master/gegl/gegl-introspection-support.h There are tests here that shows how it gets used https://github.com/GNOME/gegl/tree/master/tests/python

Adding introspection to Babl proved impossible without changing the API, due to the strict conventions that GI requires. https://bugzilla.gnome.org/show_bug.cgi?id=673422

Thanks for the feedback on that.

--
Jon Nordby - www.jonnor.com

On 12 February 2015 at 20:50, Jon Nordby wrote:

On 12 February 2015 at 06:30, 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.

That can be seen as a feature, it makes sure fixes go upstream, which makes it work for every language supported by GI - not just with one particular binding.

No doubt about that - if it is being used. But for a moment looking at the state of lack of documentation, I thought it might have been given up.

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)

Due to bug in GI, or changes in GEGL?

Probably changes in GEGL - I will try to take a look this weekend - I was already using a non-standard constructor as I said (maybe it was Sabo's wrapper you mentioned in the other message. If so, that is broken now)

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.

If we have not changed the default go be --with-introspection, we should do that now. But yes, it will only work for GEGL 0.3+

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?

I think if we added testcases for consuming GEGL though Python/GI to upstream GEGL we would catch (& hopefully fix) breakages early. If we include the bindings library you have created in upstream GEGL to provide more Pythonic syntax, we could also add testcases for that. We should then ship it by default I think.

I don't see the GNOME ecosystem switching away from GI anytime soon. And despite the pains (docs, bugs, annotations upstream), I do think the model is better than hand-writing bindings...

There are tests in my module - possibly not many as there could be - I'd like to keep the its git separated due to the Python packaging ecosystem (and merging the histories would be a mess, I guess). Do you think it could work as a git submodule in GEGL?

js ->

--
Jon Nordby - www.jonnor.com