I already found this one and it only handles enabling/disabling items based on dialog selections.
AND it does this only for C and not for Python.
Some examples on how to, for example, add event handlers to UI elements, seems to not exist anywhere. Where is the point of being able to place buttons if I can’t register an “on click” event for it?
There is decent documentation online for things like that; I usually google for python gtk3 [whatever I’m trying to do], e.g. gtk3 python button onlick, and can usually find examples at least for common widget operations. Or start with a tutorial, like The Python GTK+ 3 Tutorial — Python GTK+ 3 Tutorial 3.4 documentation
I suspect you actually could run a TkInter UI from a GIMP plug-in, but personally I stick with GTK for GIMP plug-ins since the rest of the GUI is in GTK, even though I’ve switched to using TkInter for most other projects.
What part of the tutorial are you referring to exactly? IIRC when I wrote this tutorial, I made so that I reimplement exactly the same code in Python as I did in C. Now arguably I may not have explained the correspondances with as much details in the Python part of the tutorial, as I assumed people would make the code comparison and links themselves.
But if I missed some part (i.e. I did not translate some C code to the Python version), please tell us which so that we can fix it (I don’t really understand what “enabling/disabling items based on dialog selections” refers to here).
So yeah our API is based on GTK. We documented the stuff we added over it, in particular generation of dialogs and widgets based on plug-in arguments and the like, to simplify the life for most basic plug-ins. But if you have a more complex use case, you can still definitely use generic GLib/GObject/GTK API and do completely custom code (or a mix of our generated dialog with a bit of custom GTK code in there).
For instance, when you ask:
You can indeed do this, even for generated widgets (which are just GTK widgets in the end, sometimes custom ones, sometimes not), by listening to signals or property changes. For this you want to look which signals or properties are available on a given widget. If it’s a custom widget, you’ll want to look at our API reference as linked by @brunvonlope. For instance, say you have a GimpColorButton, you could connect a handler to the “color” property or “color-changed” signal if you wanted to do something particular when the chosen color changes. To do this, just document yourself on GObject API (i.e. read a GObject tutorial).
Our tutorial doesn’t document these parts at all indeed, and won’t because it’s already better documented elsewhere.
The other part is that we simply use GObject-Introspection for our bindings, so our Python API is not our own custom stuff. Checking out a pygobject tutorial (pygobject is the Python GObject-Introspection binding) explains how things are done and translated from C API.
Now maybe what we could add in our tutorial are links to various external resources to document oneself to these other parts we rely on. The link given by @akkana is indeed very good as it documents both the pygobject binding and the GTK API in this binding in a single tutorial (which I haven’t read but it seems quite a big tutorial and probably interesting).
Probably I’ll have a look for various tutorials to these dependencies of ours to suggest as hints to go further at the end of our tutorial.
Well personally I feel it’s pretty well documented since it’s basically GLib/GTK with our small additional layer (libgimp and libgimpui) over these. And these libs have many tutorials and examples around (by being used by hundreds of software, included all of GNOME ecosystem), as well as books, etc. But if you absolutely want to use another toolkit, it’s absolutely possible. The GUI doesn’t have to be GTK absolutely (or it could even be a different version of GTK, such as GTK4, if one absolutely wanted it to)! That’s why we have a separated libgimpui library. Typically a plug-in which would want to bring its own toolkit would only link libgimp.
You won’t be the first and won’t be the last to do this.
Now that also means your plug-in may feel less integrated (it will look a bit different), will have to load a whole new toolkit while GTK3 is already in memory; but also as we are working on an extension platform, if you are planning to distribute your plug-in, it might make the whole packaging more complicated. Indeed you’d have to also package non “standard” (for GIMP) dependencies, such as your toolkit library. These are not tasks to take lightly as you may discover that packaging may be its own little hell (which is why in GIMP we are happy to have expert people like @brunvonlope for this now! ). Especially if you plan on supporting several OSes.
Our extension platform is not public yet and we’ll obviously experiment stuff and try to give good practice tips to extension makers to help with the publication/packaging part. But I know from experience that while theoretically some things feel like it’ll be smooth, the reality is often harsher. Also we won’t obviously support as much the plug-ins-using-their-own-toolkit case as the ones using GTK.
Bottom line: you absolutely can use something else than GTK3 and we won’t ever forbid it or make it hard/impossible on purpose, but it’s not the standard and really supported use case. So I would advise people to stick to GTK when doing GIMP plug-ins. But then everyone is free!
). Especially if you plan on supporting several OSes.