Though it's not visible and could happily wait for after GIMP 3 release, this
was annoying when grepping. Just did a quick cleanup.
I also removed gimprc.common which is a forgotten remnant from the autotools
build.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
As hinted in d09a2a6f
We now use the word 'bundle' to signify "program files in the same prefix"
(e.g. .appimage, .zip, .app). This is in line with our source and dev-docs
(just take a search in the repo). So, appimage and windows scripts changed.
The word 'package' normally means "program files distributed for install in
the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake
naming of some commands, but meson prefers to call 'dist', which we use more.
So, this partly reverts some things of GNOME/gimp!1171 and reinforce others
for even more "rationality" in the overall build structure of GIMP.
… since forever anyway!
GIMP used to have a second export dialog, a generically generated one, appearing
either before or after (depending on when gimp_export_image() was called) the
custom export dialog implemented by the plug-in code. This has been hidden deep
in code since forever (since version 2.8.0 in fact, I believe) and only kept
hidden behind an environment variable "GIMP_INTERACTIVE_EXPORT". I don't think
we'll ever revive this, so let's clean up.
In fact, not one, but in worst case even 2 more dialogs were hidden behind this
variable! The first dialog (confirm_save_dialog()) was a confirmation when the
selected drawable was a layer mask or a channel (and not a layer). Most export
code don't even seem to care about the selected drawables anymore anyway (cf.
issue #7370), except with gimp_file_save() non-interactively (issue #8855),
which is a real mess of inconsistency anyway.
The second dialog (export_dialog()) was listing the various actions to do on a
copy of the image to help the plug-in (e.g. merge layers/flatten image, etc.)
and possibly give choices to some of these actions. Though there is definitely
no reason to request this kind of thing anymore, especially for a short-lasting
image copy, the list of action could still be interesting in the future, not as
information of what is going to be done, but as information of the kind of data
loss of the exported format. I could imagine we want to be able to reuse such
information for generating types of data loss per format in the export dialog,
in particular in the context of my long-term export workflow refactoring (from
which resizing before export such as #2531 are part of, but the whole
refactoring project is much wider).
In the whole discussion of #5858, there will be the question on whether we don't
want plug-ins to be directly given a "ready-to-use" image depending on
capabilities they advertized in create_procedure().
Should resolve#11370
Per Pippin, HSV double is not a valid
color model for babl. We need to change
to HSV float to resolve the warning when
selecting colors on the Color Wheel.
This is a well know problem documented in GitLab docs that happens when
the CI isn't properly configured that was causing double pipelines in MRs.
Let's fix it, and reduce some redundancy.
This line should have never been pushed (in commit a78c41d2a3), my bad! It was
an early (extremely ugly and bad!) attempt to try and have the bindings see the
libraries another way than using DYLD_LIBRARY_PATH (which was instead resolved
with commit 3e980d5ad4).
This omission went unnoticed until I add `set -e` very likely as this failed
command would stop the script in failure.
- gimp_rgb_list_names() ported as gimp_color_list_names() using NUL-terminated
GimpColorArray.
- GimpColorHexEntry uses the new function (and is therefore now GimpRGB free!).
- gimp_rgb_parse_name() deleted as it's unused since my previous commit.
With all this, gimprgb-parse.c is now deleted from the repository! \o/
I suppose the intention of having this stage at the end was to make clear: no
job depends on it. However, this place is not common or ideal but one of two:
1) before building, which is more linear; or 2) after building (the choosen)
even if this isn't dynamic analysis (tests), since they are both related and
some compilers and build systems do static analysis. Anyway, not after dist.
The new place is a bit more clear to devs used at "build, test, deploy" praxis
and maybe will be now better noticed by the existing devs before distributing.
It's not perfect, since I explained above that there are two places/approaches.
Obviously, the stage continues to be OPTIONAL to pass, nothing was changed.
---
Also, dropped the deprecated "only:" (in clang-format job) in favor of "rules:"
and made the artifacts paths of clang-format and cppcheck more consistent.
Fix tests broken by changes to gimp_data, wilber.png=>gimp-logo.png
Uncomment failing tests whose issue was fixed.
Remove calls to deprecated functions.
Make more test files use v3 binding script-fu-use-v3
Compare floats relatively by epsilon.
Add some missing tests.
… 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 usable in some other bindings which ignore the (skip)
annotation; apparently some do this).
- "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.
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!
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.
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.
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().
Jehan