Since dist-installer-weekly doesn't depend on gimp-debian-x64 anymore, we need
to grab the config.h from one of the other dependencies. Let's use the one from
gimp-win-a64 (though it could have been any other Windows build job).
Fixes:
> Get-Content : Cannot bind argument to parameter 'Path' because it is an empty string.
> At C:\_r\_builds\vJWzEqDv\0\GNOME\gimp\build\windows\gitlab-ci\4_dist-gimp-inno.ps1:13 char:39
> + $GIMP_VERSION = Get-Content -Path "$CONFIG_PATH" | Select ...
> + ~~~~~~~~~~~~~~
> + CategoryInfo : InvalidData: (:) [Get-Content], ParameterBindingValidationException
> + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.GetC
> ontentCommand
The dependency to libomp apparently came with the move to CLang.
Fixes:
> /builds/GNOME/gimp/_install-debian-x64/bin/gimp-console-2.99: error while loading shared libraries: libomp.so.5: cannot open shared object file: No such file or directory
When running GIMP in the build environment (even before it's installed), we
don't want to "fix" paths. We had the case in particular on the macOS CI where
the install PREFIX was a parent directory of the build directory and therefore
we were "fixing" some perfectly good constructed directories (set by meson) into
non-existing folder paths.
Additionally this codepath should only run when ENABLE_RELOCATABLE_RESOURCES is
set (even though this alone would not have fixed our CI issue because the macOS
build is relocatable).
Finally I am updating the gimp-data repository so that libraries are properly
found from the (now correct thanks to this commit) paths set by meson when
running gimp-console from within the build directory.
When the config directory is set by an environment variable, the version is
likely not part of the directory path, and therefore strstr() would return NULL.
Fixes:
> (gimp-console-2.99:41446): GLib-CRITICAL **: 13:19:34.933: g_vsnprintf: assertion 'n == 0 || string != NULL' failed
Now the development and stable logos will be generated from gimp-data.
In other changes, the gi-docgen logo is installed as a symlink using
install_symlink() which exists since meson 0.61.0 so I bumped our meson
dependency (in practice we were already using this function anyway and Debian
bookworm has meson 1.0.1 so it's all good).
Finally I don't install a wilber.png anymore, which was only used by script-fu
testing, and which was the same as gimp-logo.png (except 256x256 instead of
128x128). Unless mistaken, all script-fu tests loading this image still work
with the change. The only one where I needed further change was buffer.scm
(which was checking the dimensions).
See gimp-data@9aa6e35.
- With last commit, the Windows installer pipeline doesn't depend on
"gimp-debian-x64" job anymore since a native Windows build is now able to run
GIMP (or gimp-console) as a build-time tool as well. It makes the Windows
installer pipeline (and full custom native builds) self-sufficient.
- On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require
"gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in
order to generate some image data (such as the splash image, and probably soon
logo or icons, etc.). See gimp-data@5a03c71.
- Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of
"image-debian-x64" for all Debian as well as the cross-compilation jobs. They
are all based on the same Debian image (it was debian:bookworm for native
Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork
for all) and it's just a few more packages (cross-compilation C and C++
toolchains) for the cross-builds. Moreover now the cross-builds also need the
native GIMP binary around, therefore native dependencies are needed as well.
It makes sense to factorize all 3 images into 1.
- Make sure we don't build bindings when cross-compiling since these won't work
in this case.
This commit is in conjunction of gimp-data@d273a18 and finally makes Windows
build able to run GIMP main binary itself (or gimp-console) in order to create
various images, before the installation step.
- Use the new GIMP_TESTING_INTERPRETER_DIRS environment variable for uninstalled
binary to find the .interp files (in particular because our build scripts are
usually Python scripts these days).
- Use the new GIMP_TESTING_ENVIRON_DIRS environment variable to find .env files
(actually running uninstalled GIMP binaries did run without this one, but it's
not a bad idea to add support anyway.
The python.env file sets a ':' separator for GI_TYPELIB_PATH environment
variable, which breaks finding the correct typelib files in the CI, when also
manually setting a previous value for this environment variable.
I'm not entirely sure the rule of swapping ':' for ';' is universally true on
Windows, whichever the variable. Let's hope that it is.
- Splash images will now be stored from gimp-data.
- The installer BMP image scripts also move in the same time.
- We don't need devel and non-devel variants of the BMP images in InnoSetup
scripts since the images are generated from the actual splash.
Meson subprojects just have too many problems and limitations and I can foresee
the maintenance headache and the future incoming false-positive bug reports if
we start using meson subprojects.
Comparing to the simplicity of git submodule which also has much better
notifications to help people understand when the submodule is not in sync and
how to remedy to it.
See commit gimp-data@c364adb explaining the main reasons in detail.
Note that the executables are not built yet at this point, but we just need to
pass the name for configuration. The gimp.ico generation step is run manually
anyway and requires a fully functional and installed GIMP.
See commit gimp-data@40d4822.
This commit is separate from the previous to make it immediately clear (by
comparing files) that the previous commit is a simple move with no modification
whatsoever of the icons/ directory, i.e. the symmetrical removal of add commit
gimp-data@8b54490.
We now clone gimp-data as a meson subproject. I am currently testing the
subproject feature though I am doubting a bit because of its limitations: the
git clone is not updated automatically, nor are errors clear. Therefore it would
be easy to end up with outdated data for developers not manually and regularly
running:
> meson subprojects update
Worse, it looks like even when updating the suproject, it fails to be properly
reconfigured. See: https://github.com/mesonbuild/meson/issues/12898
In our efforts to use Clang, now the nightly (in fact weekly) flatpak
is built with Clang too, not only GIMP but also the dependencies.
* However, not aalib. We welcome fixes regarding this cursed lib.
Additionally, updated some build options from some deps.
Resolves#7672
The Plasma wrapper gets the boundaries
of its filter area using gimp_item_mask_intersect().
If used on a selection, this gives the x and y
coordinates relative to the total canvas.
However, the GEGL operation will be drawn
relative to the selection - so this offsets
the effect within the selection rather than
filling the full space.
This patch fixes the problem by setting
the x and y position to 0 when there is an
active selection.
Layer effects that have not yet been committed are not
attached to the drawable. Trying to reorder them causes a
crash since they're required to be attached for undo/redo
purposes. This patch checks if they're committed beforehand,
and informs the user with a warning if it's not possible.
In GIMP 2.10 the number of segments was restricted to MAX_FANS.
That was later changed to 1024 without increasing MAX_FANS
which can crash the plug-in.
Also change the max displacement angle back to 90 degrees. The interval
0 to 90 degrees is enough to return all possible values.
Fixes#11108
...to fully use and return GeglColor.
Also, fix gimptext-parasite sending a
GimpRGB to create a GimpText instead of
the now required GeglColor, and update
documentation in gimp_checks_get_colors
to reference GeglColor instead of GimpRGB.
Resolves#11092
Same fix as in 2b3b2af2, since Blinds and Jigsaw
were the two plug-ins which used GimpAspectPreview
before the port to GimpProcedureDialog.
After the port to gimp_procedure_dialog_get_drawable_preview (),
the preview widget was being sized to the original drawable's dimensions
while the drawable was being redrawn with only its thumbnail dimensions.
This created a scrollbar that showed unallocated/overwritten buffers.
To fix, we update the preview size and boundaries whenever the preview
is changed. This removes the scrollbar and returns to 2.10 behavior.
In addition to the port, mnemonics were added to both file-pdf-save-multi
and file-pdf-save's GUI parameters.
Some runtime warnings were also fixed, such as trying to use a NULL string
parameters to make a file and trying to access properties from file-pdf-save
that don't exist in file-pdf-save-multi.
