- Mar 28, 2024
-
-
Jacob Boerema authored
When loading a PSD with multiple extra layer channels, the PSD loader crashes. We increase the number of layer_channels with 2 for every extra channel found, which we only should do for the first extra to skip the alpha channel. We fix this by adding a check to see if this is the first extra channel and in that case skip the alpha channel slot. Any other extra channel will be added in the next available slot. We also add an extra check in case we have extra channels when we do not have an alpha channel in the layer. Not sure howe likely this is. In that case we move the last extra channel to the slot reserved for the alpha channel. That way we won't try to free non-existent alpha channel data. Note that eventually we should probably try to add these extra layer channels are extra image channels in GIMP, since GIMP doesn't have the concept of extra channels per layer.
-
-
Alx Sa authored
Connected anti-aliasing GUI to a property so that script writers could also configure this when running the plug-in.
-
-
-
-
-
Alx Sa authored
The border-drawing code for Layer icons has been ported to GeglColor. Note that GimpViewRenderer still uses GimpRGB for gimp_cairo_checkerboard_create (), which will be fixed in a larger commit. In 9bee3bed, Border Average's return value was set to NULL rather than a valid GeglColor when the procedure was created, which caused a warning on launch. This has been fixed.
-
Perspective shadow could call plug-in-gauss-rle with higher blur radius than allowed in the wrapper. Raise the max value to allow for this. Fixes #11140
-
Jehan authored
Now that the MR gimp-data!1 has been merged, we can pull the main branch. Also syncing to latest commit to fix "dev-docs" job.
-
- Mar 27, 2024
-
-
Jehan authored
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
-
Jehan authored
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
-
Jehan authored
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.
-
Jehan authored
Fixes: > (gimp-2.99:3763): GLib-CRITICAL **: 19:31:02.392: g_hash_table_size: assertion 'hash_table != NULL' failed > GIMP-CRITICAL: gimp_translation_store_constructed: assertion 'lang_list != NULL' failed
-
Jehan authored
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
-
Jehan authored
-
Jehan authored
-
Jehan authored
-
Jehan authored
-
Jehan authored
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@9aa6e351.
-
Jehan authored
- 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@5a03c716. - 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.
-
Jehan authored
This commit is in conjunction of gimp-data@d273a187 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.
-
Jehan authored
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.
-
Jehan authored
Fixes: > libgimpbase/gimpchoice.c:240: Warning: Gimp: gimp_choice_list_nicks: unknown parameter 'nick' in documentation comment
-
Jehan authored
-
Jehan authored
-
Jehan authored
- 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.
-
Jehan authored
Not sure why it doesn't already since `set -e` stops the script immediately and crossroad is supposed to pass the return value through.
-
Jehan authored
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@c364adb8 explaining the main reasons in detail.
-
Jehan authored
-
Jehan authored
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@40d4822a.
-
Jehan authored
Symmetric removal commit of add commit gimp-data@c09aa01c.
-
Jehan authored
-
Jehan authored
This is the symmetrical removal commit of the add commit gimp-data@299204f2.
-
Jehan authored
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@8b544909. 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
-
Jehan authored
-
Bruno Lopes authored
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.
-
Alx Sa authored
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.
-
Jordi Mas authored
-
-