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).