- Feb 18, 2025
-
-
Jehan authored
First of all, let's init with the main procedure label (stripped of leading/traling spaces, of mnemonic underscore and of ellipsis) as progress status for gimp_progress_init(). Then reuse this main label for all subsequent progress updates by the same top procedure. Finally "pulse" the progress at each update to make it more like progression actually happens. This is a first experiment to see if not having progress API in Script-Fu is fine (#12948), by having better progression defaults.
-
Jehan authored
Note that I don't touch the GimpFileProcedure and children because they are special-cased anyway. As for GimpBatchProcedure, ALWAYS is a good default too.
-
- Feb 17, 2025
-
-
Jehan authored
This was removed by commit 38b18de7 because this operation doesn't exist anymore and was replaced years ago. Even though it was not wrong, let's be over-cautious rather than not enough. What if someone had still a binary of this old operation lying around? This doesn't cost much to keep it in the list, so let's just do it (with a comment to still document it doesn't even exist anymore).
-
Jehan authored
-
Jehan authored
Since the move of GimpUnit from some weird int/enum mixed type into a proper object type, this was not usable anymore in Script-Fu. Functions like (gimp-text-layer-new) were therefore broken. It now works again.
-
Jehan authored
Even though the libgimp wrapper has annotations, it is still possible to pass a NULL font through, in Script-Fu for instance by not passing all arguments (and very likely in a plug-in by calling the PDB procedure directly rather). And unfortunately this would crash GIMP when it tries to work on the NULL font. Let's do some sanity check!
-
-
Bruno authored
The previous code was inconditionally patching all the lang files, even the ones which we don't use. Let's fix that using the "langs*" arrays.
-
Bruno authored
-
Bruno authored
Now, we can use whatever variable we want from 'config.h' with its value, unlike the previous code which was hardcoded and did not worked at all for variables with custom values like GIMP_RC_VERSION. (Note: there are still work to do with Inno scripts)
-
-
- Feb 16, 2025
-
-
Bruno authored
Also, fixes CUSTOM_GIMP_VERSION format.
-
Anders Jonsson authored
-
Bruno authored
It was caused by GTK finding host's canberra or others modules, which is goappimage fault: https://github.com/probonopd/go-appimage/issues/332 This bug will remain if the distro have some uncommon module (e.g. appmenu, colorreload), since we don't ship them.
-
Jordi Mas authored
-
- Feb 15, 2025
-
-
Jordi Mas authored
-
-
Jehan authored
Without this, we cannot set NULL (or equivalent, such as None in Python 3) when calling these functions in bindings.
-
Jehan authored
-
Alx Sa authored
In 9e8499bb, we forced image and drawable previews to be 8 bit integer for compatibility. However, this affects image previews when in higher precisions, leading to banding and other conversion issues. Since the color space invasion, the original problem should have less of an impact as GIMP now handles conversions between profiles much better. Therefore, we will just grab the existing format for Grayscale and RGB images, rather than forcing a precision change to 8 bit.
-
- Feb 14, 2025
-
-
Jacob Boerema authored
As discussed on IRC these ops mostly duplicate other gegl ops and have some shortcomings: range and gui-range, among other things, are currently not supported. This causes some issues changing values of parameters in GIMP, see e.g. gegl#403 Since they bring nothing new, and have issues, we will blacklist them from the GEGL tools interface in GIMP, at least until they have better support in GEGL.
-
-
-
-
Jehan authored
After discussing with NikcDC and Wormnest on IRC, we agreed that maybe a default of being sensitive when one or more drawables are selected seems better, since the run() signature now has an array of drawables. So most plug-in developers will consider the case when there are several selected drawables as an obvious possible case. And if someone really doesn't want to handle this case, they can always set the sensitivity mask explicitly.
-
Jehan authored
In particular, when setting a sensitivity mask but no image types, the procedure was always sensitive. Also make gimp_plug_in_procedure_get_sensitive() more robust.
-
Jehan authored
-
Jehan authored
This is markup format where the asterisk has some special meaning.
-
Jehan authored
-
Jehan authored
-
Alx Sa authored
Resolves #12854 Previously when loading filters, we used gimp_drawable_filter_apply (). If there was also an active selection, it affected the recreation of the filter and distorted the display. This patch switches to using gimp_drawable_filter_apply_with_mask () so that the filter's mask is always used instead, no matter if there is an active selection or not.
-
Jacob Boerema authored
gegl:pack replaced gegl:hstack almost 5 years ago, but the blacklist for not showing it in our list of ops in Gegl tool was never updated. Since Pack is also causing issues in GIMP, see #12890 and #12902, let's update the blacklist add it there and remove the old gegl:hstack that has been removed from GEGL.
-
-
Bruno authored
-
-