Some great examples of how to write Python plugins for Gimp-3.0
https://gitlab.com/gimp1614946/gimphelpers



Even with Gegl operations (Choice demo uses 'gegl:gaussian-blur'):

Thanks MareroQ for bringing this resource to light. There's nothing like having an example to help a programmer put code together.

I am really hoping to get into Python scripting Gimp 3.0 plug-ins next year. This is going to help me immensely.
Thanks Ofnuts!

Also updated here:
Useful links for downloading plugins/scripts
viewtopic.php?f=9&t=18452

I'm reading Learn Python The Right Way I agree with what the author says about C and Java both really hard to master. I noticed some of the Gimp 3 python plugins are compiled into an exe like C files.

C, possibly, full of traps and small details you have to care for.

Java, no. Java can be a bit verbose, but when your Java code compiles, it sort of makes sense. In Java, you can't add Apples and Oranges, unless the receiving variable is a count of Fruit. In Python, your first runs are mostly trying to catch typos in variable names and other completely stupid mistakes. You can improve things in Python by using an IDE and using the "type hints" that have been introduced in Python 3.8 so you can write something like:



then if you try to call that constructor with something other than a ProcedureConfig and a bunch of strings the IDE will show you the error right away, and when doing code completion you can even hope that it will suggest variables that already have the right type.

Of course it starts to look like Java, where you have to know what you are doing and where you are going.

But then I'm writing a lot of Python3 code these days, and this helps immensely. I even enjoy times where the code runs on the first try!



Uh? The only reason to do this would be to hide the code, because this kind of "compilation" is more like packaging the code and a Python runtime in a bi blob. What you can see in Gimp is a __pycache__ directory, where code compiled on the fly in a previous run is kept in the cache to avoid being recompiled on subsequent runs. Since in Gimp3 plug-ins are all in their own directory, it is easy to distribute the plug-in with separate module files and these end-up precompiled in __pycache__.

@ofnuts

There are 23 types of variables possible in Gimp-2.10.xx.
Are the missing ones in Gimp 3 the developers' choice or Yours?

Still not in Gimp3. My equivalent to this is the "full-dialog" file that you will find on gitlab?

GimpHelpers implements all that works so far.

There are two kind of missing things, those that were variants of the same type of arg:

- Slider/spinner/float/int, now you just have Double or Int, but you also have +/- buttons
- Option/Radio are Choice
- Toggle is Boolean (but I prefer to use Choice)

And those that don't exist yet:

- IMAGE (should be implemented soon)
- PATH/VECTORS
- FILENAME, DIRNAME and DIRECTORY (AFAIK the difference is that FILE/DIRECTORY must exist (used for read) while FILENAME/DIRNAME can be created (overlooked by the dev, I have an outstanding issue on this that you can upvote.
- TEXT (multi-line text)
- LayerGroup

For my own scripts the main blockers are PATH (obviously..) and DIRNAME (many scripts exporting things). For IMAGE for the time being I use a LAYER selector, and then obtain the image from the layer).

My latest addition to the code is a simplified way to call the PDB items (mostly things that aren't part of the base API, such as plugins. For instance:

Those files are here:
/usr/lib/x86_64-linux-gnu/gimp/3.0/plug-ins/
An example is file-rawtherapee/file-rawtherapee
Everything listed as 'file' is an executable. They must be compiled C code and they are called 'plug-ins'.

Python console is there as 'python-console.py' but script-fu is an exe.

RT is in not written in Python, probably written in C or C++.

Plugins can be written in a variety of languages. On Unix, with the magic of the "shebang" (the top line that starts with "#!") you don't need to know where the code comes from: if it's a compiled binary it can be loaded and run right away, but if the loader doesn't recognize the binary format it looks for a shebang and uses it to start the adequate interpreter on the file. So in addition to compiled plugins (mostly C and C++, perhaps Rust & Golang too) you can have interpreted plugins (Python, Lua...). So, on Linux at least Gimp is completely language-agnostic when it comes to plugins.

Scripts are different animals, they have to be submitted to the script-fu executor to be run.