As for a reason to not do it, my (perhaps misinformed) understanding is
that there is a goal to make
gimp not target a specific scripting language; that is to equally support
have example plugins in /plug-ins/goat-exercises), the same as Python.
If you add a GimpFu module for Python, it wont be available for other
languages. Support for other languages might
call for adding additional GimpFu modules for each, and thus adding more
To my understanding, this language-specific support is what is being
Maybe a better approach would be to have the GimpFu implemented in C, in a
way that it will be available to all scripting languages.
I think GimpFu is very useful to novice plugin authors and should be
retained for that reason. GimpFu provides a much simpler, approachable
API, and is the part that generates the GUI automatically.
Also, there are probably thousands of plugins that use Gimpfu (granted,
many are trivial and rarely used.) So it seems useful to port GimpFu for
Re: goal to support all languages equally. That would be nice, but I don't
know how to do it. Also, even if GimpFu is implemented in Python, couldn't
it be available to all languages via GI? That is, GimpFu doesn't have to
be implemented in C to be available across languages? So I think a good
strategy is to port GimpFu still in Python (a high level language where
many can contribute quickly) and then proceed to make it cross-language
I am still confused about exactly what parts of PyGimp need to be ported to
be able to say GimpFu has been ported. I think much of PyGimp falls by the
wayside. Or at least the code is much smaller and easy to understand.
I have made some progress, see my repository, which has some design
documents. But there could be many mistakes.
On Sat, Jan 11, 2020 at 1:55 PM Lloyd Konneker via gimp-developer-list wrote:
> Alexandre: Yes, that code, in master (2.99, the “dev” branch for Gimp 3)
> In that branch, the Makefile.am has commented out the pygimp sub directory,
> and the meson script does not subdir the pygimp directory (doesn’t try to build it.)
> So an onlooker like myself wonders whether it is abandoned, or just waiting for someone to work on it.
> Maybe there was a prior discussion about it, maybe a private discussion?
Around autumn 2019, GIMP in the master branch was ported to use
GObject introspection (https://gi.readthedocs.io/en/latest/) and
understanding from talking to Jehan is that he ported some of the
existing plug-ins to Python 3 and moved them to
rest was disabled from building/installing. According to Jehan, Elad
looked into other Python plugins and found out only two of them make
sense to be ported (I don't know which ones exactly, Elad will
Of course, there are also 3rd party Python plugins like the one you
ship with Resynthesizer.
Alex: yes, I understood most of that by browsing the repository, but it is good to restate it for other readers.
Some plugins, like foggify.py have been ported, but only partially, without the GUI. If you look at the history (in the repository), you can see that it formerly was a “gimpfu” plugin i.e. it “from gimpfu import *”.
If gimpfu had been ported first, the former foggify.py might work without porting (or just minor changes.) I am not trying to criticize the order in which things were done, I realize that the port of foggify was pioneering, to test the machinery at lower levels. I have looked at the ported code myself to see how to do things (although I think despeckle.c or some other might be a more definitive, complete example of all the things a well-behaved plugin should do.)
GimpFu simplifies writing plugins in Python. It generates GUI dialog automatically, provides aliases “gimp” and “pdb”, and has only two other methods “register” and “main”. So loosely speaking you can write a gimpfu plugin knowing little more than the PDB.
Other parts of PyGimp provide pythonic classes for Gimp classes, such as “gimp.Image” (note the lower case “g”, it is not the gobject introspected Gimp.Image.) These classes have many “convenience” methods (not found elsewhere?) Many plugins that use gimpfu also use the convenience classes.
I can see that the PyGimp classes are now less useful, since now GI gives you much the same thing. All an author needs to do is translate from the language of the PyGimp classes to the very similar language of GI of Gimp.
To elaborate my original question: has anyone decided that the convenience of gimpfu (and/or the other parts of PyGimp) is not useful anymore? I gather that the answer is: some of it might be useful, we just haven’t done it yet, its much, hard work, and noone understands the code anymore.
If there are plans to automatically generate plugin GUI, but implemented cross-language, as Elad suggested….. then any port of gimpfu could omit writing that in Python and introspected gtk3.
I think the gimpshelf module of pygimp (that provides session persistent storage, mainly for plugin settings) is deprecated because the capability is in Gimp class gimp_procedure_config now.
I think the gimpui module of pygimp (that lets authors use libgimpui i.e. Gimp provided widgets e.g. color picker) could be deprecated because authors can use GI, and as far as I can determine, there are extremely few plugins in the wild that ever used it.