… test-color-parser.c file.

The file libgimpcolor/test-color-parser.c was compiled but never actually called
by the build. Now that we have a nice infrastructure to test libgimp API, I am
moving it there with the new format. Doing this also allowed me to discover some
bugs in CSS parsing, as well as discover Python binding was failing here (cf.
the few previous commits).

Only one test is disabled so far, the one where 4 digits are used per channel in
hexadecimal notation: "#64649595eded". This format simply doesn't appear
anywhere in the spec, and also the result values in the samples listing don't
even fit. So far, I'm just unsure what to do with it, if we want to keep this
support (of some kind of higher precision hex notation, but not specified, so is
it even used by anyone?) or not.

All the other tests just work in both C and Python!

New functions with the same name as these functions are created, except without
the length argument (i.e. it's equivalent to calling these with -1).

The reason for this is that using strings with a length variant which may be
negative to switch to NUL-terminated strings are not bindable. At least in our
case, when testing in Python, the input string ended up as corrupted garbage and
GObject Introspection docs warns about such interfaces:

> In particular, avoid functions taking a const char * with a signed length that
> can be set to a negative value to let the function compute the string length
> in bytes. These functions are hard to bind, and require manual overrides.

(see: https://gi.readthedocs.io/en/latest/writingbindableapis.html#strings)

So instead, I create a simple version which runs on NUL-terminated strings only
and which is bound, whereas unbinding the generic length-version (making it
C-only, or maybe us...

- "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!