[Gimp-developer] Fixing the Python story for GIMP 2.10

[Kristian Rietveld <kris loopnest org>]

Hello everybody,

At LGM I got dragged into GIMP's Python plug-in. The main question
regarding GIMP's Python plug-in is how to incorporate support for GEGL
for the GIMP 2.10 release. This may seem rather trivial, but unfortunately
this is not the case. In this e-mail I will briefly explain the problem
and a proposed solution. A more detailed analysis of the other possible
options can be found at the bottom of this e-mail for the interested
reader.

I would like to thank João Bueno for thinking along and providing his
insights, which have been merged into this e-mail.


Problem
-------

Python bindings already exist for both GIMP and Gegl. The main problem
is that both of these bindings have been built on top of different,
incompatible frameworks. The GIMP bindings rely on GTK+ 2 and PyGTK, and
these bindings are "static" in nature. On the other hand, the Gegl
bindings were written using GObject introspection and PyGObject 3 (also
known as PyGI), bindings which are "dynamic" in nature.

So, what would happen here is that all GTK+ and gimpui objects are
constructed through PyGObject 2 (PyGTK) and all Gegl objects are
constructed through PyGObject 3. Unfortunately, using PyGObject 2 and
PyGObject 3 within the same process is not really supported, in fact we
can summarize that PyGTK and PyGI are not compatible with each other.
Furthermore, using GTK+ 2 with PyGI is not recommended. For a more
detailed evaluation of the different possibilities, see the bottom of
this e-mail.


A Proposal for GIMP 2.10
------------------------

After careful evaluation of the possibilities, it seems like the most
feasible option for GIMP 2.10 is to introduce Gegl bindings that function
on top of PyGObject 2. It is pretty much guaranteed to be stable and
compatibility with current plug-ins will not be broken.

This will involve the generation of old-style, "static" bindings for Gegl.
The result is that all of GTK+, gimpui and Gegl will be PyGObject 2-based.
It is important that this is very clearly documented, as this might be a
little confusing to the users. For a short period of time, there will be
two Gegl bindings: the ones we already have and the ones that will be
introduced in GIMP 2.10. Furthermore, the "static" bindings introduced
with GIMP 2.10 will be immediately deprecated and likely be removed in
GIMP 3.0.

To generate this static binding, we can very likely write a script that
rewrites the existing GIR XML (which is the source for the PyGObject 3
bindings) into suitable .defs files from which the code for the static
bindings can be generated. I don't think this will involve a lot of hand
work.

What is important, is to work on compatibility with the future GIMP 3.0
bindings. João is working on a more higher level binding for Gegl. This
binding can be in place for both the 2.10 and 3.x bindings to ensure
compatibility. To work on providing compatibility, it might be worthwhile
to work on the 2.10 and 3.x bindings in parallel, by already starting to
port the Python bindings to PyGObject 3 in the gtk3-port branch.


Road to GIMP 3.0
----------------

For GIMP 3.0, quite some work on the Python bindings will be necessary.
The main aims are:

- Move to PyGObject 3 and GTK+ 3.0. During this process, many of the
  C-code of the Python bindings can be removed, or rewritten as Python
  code.  libgimp et al. are to be made introspectable where possible.
- Move to Python 3.0.

After this has been achieved, we will not have to break the bindings again
for quite a while. As has been mentioned above, this work could already
start in the gtk3-port branch and be done in parallel with the work on the
2.10 bindings.



So, that's it, this would be the proposed plan. Please discuss. The
evaluation of the possibilities can be found below.


regards,

-kris.




Evaluation of Possibilities
---------------------------

## 1. Try to mix PyGTK and PyGI

In this setup, we try to use the existing bindings for GTK+, GIMP and
Gegl.

Pro:
+ Best option for the user, since current pygimp plug-ins will not be
  broken, code written using PyGTK will continue to work and for Gegl
  the existing binding using PyGI will be used.

Con:
- Mixing PyGTK and PyGI is absolutely not recommended. By default the PyGI
  bindings refrain this from being done.

We tried to work around the issues, by using a specific initialization
sequence. Still it does not work, PyGObject 2 and PyGI both try to
register a "PyGObject", only one of which can be registered at a time. One
wonders whether these two objects are compatible. We should not go here.


## 2. Move from PyGTK to PyGI

This setup would try to use GTK+ 2 through PyGI, so the existing Gegl
bindings can be re-used.

Pro:
+ Existing Gegl bindings can be reused.

Con:
- Not recommended. Many compatibility issues with GTK+ 2.
- The impression is that many existing pygimp plug-ins will require
  porting/rework. Existing plug-ins will be broken when 2.10 would be
  released and again when GIMP 3.0 is released.

Note: we have tried to use "pygtkcompat" with GTK+ 2, but this results in
crashes (it was really designed for GTK+ 3). Already trying to get the
GIMP pyconsole to run on PyGI is going to require some substantial effort.


## 3. Move Gegl bindings to be on top of PyGObject 2

Pro:
+ Option with the least technical difficulties. Guaranteed to be stable.
+ Compatibility with current pygimp plug-ins remains.

Con:
- We will temporarily end up with two Gegl bindings (until GIMP 3.0 is
  released).
- A new "static" Gegl binding has to be generated.

Note that PyGObject 2 does have code to enable introspection, however it
is disabled by default and even when you enable it, it doesn't compile.
Also this module is disabled by default such that it will not clash with
the "gi" module of PyGObject 3. The only feasible option that remains here
is to generate a new static binding.


## 4. Develop new pygimp plug-in and bindings

A new pygimp plug-in and corresponding bindings would be developed, that
would be installed in parallel with the currently existing bindings.

Pro:
+ Current plug-ins continue to use the existing bindings and are not broken.
+ New binding can be made future proof by using GTK+ 3 and Python 3
  already.  So for both GTK+ 3 and Python 3, we would not need to break
  plug-ins again in the future.

Con:
- Existing plug-ins will need to be ported to the new Python binding if
  they want to take advantage of Gegl.
- New Python plug-ins would use GTK+ 3, while GIMP is still on GTK+ 2.
  This will be a shipping nightmare for the various operating systems.

An alternative here would be to revert from GTK+ 2 to TkInter. However,
for plug-ins that want to use Gegl, this would mean porting for GIMP 2.10
and again porting for GIMP 3 (to move to GTK+ 3).