Re: [Gimp-developer] how far from 2.10?

OK, maybe I'm pessimistic here, even if some of my python scripts had to be
reworked between 2.6 and 2.8, which have far less differences than 2.8 and
2.10. Then in the current API there are still many values with 0-255 ranges
(gimp-drawable-{get|set}-pixel (),gimp-histogram) for instance. So either
there is absolutely no change in the API and the script may produce
sub-optimal results in images with high bit depth, or there is some change
and the script has to be reworked and may be made bimodal or forked to
support 2.8 and 2.10.

If the PDB/Python API is to  support even the majority  of the new
functionalities, i t will need
a lot of additions/rethink. And it is not only on the Python side.
On the other hand, It would not be nice to add a   lot of new calls to
the API for 2.10, and get those invalidated by the transition to a
GIMP 3.0 afterwards, so we better have some care in picking the new

When working from Python code, the ideal direction to go is easy to
imagine: to have a couple PDB calls to get a GEGL buffer (or source
node) returned from GIMP, and then using GEGL-based code to perform
the actual image operations, and return a node, or buffer back to

That way, one won't need to rewrite every PDB call to support several
pixel formats, and that would be valid only for GIMP 2.10.

On the other hand, it is not currently easy to use GEGL bindings to
the Python linguage -
due to tha fact that all binding is delegated to be auto-generated by
gobject introspection, which in, its turn, is only maintained for
glib3, gtk+3 - (while GEGL is tied to glib2).

I could get it working, more or less here - some calls simply crash -
and started a small project to wrap the g.i. automatically generated
objects ito things friendler to the Python developer (check, but that depends that one
sets-up g.i. and pygobject, correctly previously. And these projects
branchs to support glib2 are apparently unmaintained, and had already
bit-rot a bit. (If someone can get pygobject working cleanly with
GEGL, please do tell me and say which versions you have used)

Still, I maintain that, at least for a Python API, that would be the
better way to go - we'd have to either "unrot" pygobject + gegl
bindings, or find another route to  use GEGL from Python that would be
api-compatible to pygobject + gegl on glib3.

(So that is also my "what is missing before  2.10" in what concerns
automating GIMP via Python)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]