- "transparent" is now recognized. It was forgotten (probably because on the
  GimpRGB interface, we separated the API in a _rgb_ and a _rgba_ variant).
- rgba() and hsla() formats are now fixed (implementation was there but the
  function names were not recognized.
- Adding some comment about limitations of the hexadecimal notation (we don't
  support the alpha channel which is now in the CSS specs, while we also support
  some non-specified variant with every channel on 3 or 4 digits) for future
  work.

The lack of distinction after 975c1891 was causing crashes in local builds.

This fixes:

> plug-ins/script-fu/script-fu-refresh.c:70:1: warning: no previous declaration for ‘script_fu_register_refresh_procedure’ [-Wmissing-declarations]

This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.

Our pluginrc code is already able to output NULL for a default NULL color, but
reading was failing with the following error:

> GIMP-Error: Error while parsing '/home/jehan/.config/GIMP/2.99/pluginrc' in line 289: unexpected identifier 'NULL', expected number (integer) - fatal parse error

Let's support reading such a value now, especially as for Python plug-ins, we
are not even able to add a default value to GeglColor arguments (cf. previous
commit).

In some binding (e.g. Python), we have not found how to create GeglParamColor
specs for PDB procedures, so we use GParamObject specs with `GeglColor`
object_type. Have our code handle both variants.

Fixes:

> GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'

Of course such generic spec won't have any future option which we may add to a
dedicated param spec (and despite adding code to handle a default value, adding
a default color still doesn't work according to tests).

There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!

Like in e31de151
these now need to work on an object rather than a name.

Resolves #11347

In multi-window mode, it is possible to change images without
causing the layer effects popover to close. This results in the prior
image's layer effects being shown over the new image, which is
confusing. This patch causes the popover to automatically close
when the image is changed to prevent this problem.

AppImage is pretty fast to make, like the win crossbuild; and portable,
being very appropriate to do quick tests on Linux when pushing to git.

The overall organization of Debian jobs was changed to take advantage
of this and make things less complicated (but less clear at first sight).
I reinforce that this was the most efficent way to make the AppImage.

This fix doesn't feel right. The whole point of having a generated manifest from
the build was to use it for our flatpak job (through job dependency). Right now,
it has been rendered useless. We must either re-implement the proper job
dependency or find another way to fill the proper "command" with the right
version (maybe just a standalone script to be used in Gitlab CI and which we
could tell about to people who wish to build the nightly flatpak themselves).

Anyway for now, it should do as I don't want to spend too long on this. It
should fix this error in the log generated as artefact of the "gimp-flatpak-x64"
job:

> ../build/flatpak/meson.build:6:2: ERROR: File org.gimp.GIMP-nightly.json.in does not exist.

Syncing dependencies back and forth with the current branch, preparing for 3.0.0
RC1 release: https://github.com/flathub/org.gimp.GIMP/pull/287

Resolves #11354

Due to improvements in the text API, we have to pass a GimpFont
object as the last parameter of gimp-text-get-extents-font rather
than just a String.

These files has been generated by the installer scripts for historical reasons.
Now that we have full-blown local builds and the upcoming MS Store version,
this pervasive pratice can't continue since it creates disparity between builds.

Resolves #11337

Per Bruno Lopes, we should extend aefdb84b to also cover
dropdown box arrows and GimpSpinScale buttons.

When closing the Page Setup dialog we had warnings and criticals in
the terminal.
The cause for this was that we were looking for the temp procedure
to notify the print plug-in. However, this temp procedure is only
installed if the print plug-in is running, not when running the
Page Setup directly, in which case it is not needed.

We now check if the procedure is valid (meaning the print plug-in is
running) before calling the temp notify procedure.

Resolves #11324

Similar to 403af188, we needed to update function calls
that assumed they were receiving a GimpRGB struct rather
than a GeglColor object. Future plans including adding Gegl
functions to retrieve HSV and HSL automatically, rather than
using gegl_color_get_bytes().

Making sure not only that the PDB passes correctly the number of colors, but
taking one random color in the array and verifying it is correct.

Anders Jonsson authored Apr 18, 2024 and Jehan committed Apr 18, 2024

Fixes some scripts, followup to
c92cf7e8

Removes an index that was needed to GimpRGB, but no longer
valid now that gimp_palette_entry_get_color () returns a GeglColor
object. Also, fixed an issue in Interactive Mode where the first
valid palette would be used for every other attempt, no matter which
palette you clicked on.

Switch to using gimp_item_convert ()
instead of gimp_item_duplicate () so that
the filter mask can be properly associated
with a new image when copy/pasted.

Previously, filters were lost when copying
individual layers. This patch copies them
to the clipboard image on cut or copy,
then copies them back to the pasted
image.
It also fixes an issue where filters would
be merged down if a selection was
copied instead of the entire layer.

Color propwidgets now use GeglColor only.

We don't need to convert GimpRGB to GeglColor now as we work directly with
GeglColor!

The comment I had written back then was wrong. Meson in fact can create an env
object from another with a simple assignment (which copies the object, rather
than pointing to a same object), per the answer which has been given to me in:
https://github.com/mesonbuild/meson/issues/13045

This allows to have a properly separate environment (when using GIMP as a build
tool, we don't want to load the test files).

We are using `gimp_image_set_file` to set the filename, which
requires an extension, not doing so caused an error.
So let's add .xcf to all compose filenames.

When decomposing, the plug-in sets the filename without changing the
extension. However, gimp_image_set_file requires the filename to be
an .xcf file.

To fix this we simplified `generate_filename` to always add an
.xcf extension.
While doing this we also fixed a critical that happened when no
filename was set (new image), by testing `gimp_image_get_file` for
being NULL first.
When no filename was set it also didn't use the type when
config_as_layers was set, this is also fixed.