- Apr 27, 2024
-
-
Jacob Boerema authored
for gimp-tests.log On Linux we may not have permission to create a log at our default location, so we need to check for that. First we should not init the log when our plug-in is asked for info. Only create it when we actually run the import or export tests. Second, try to catch the permission error and write a message either in GIMP or in the terminal for non-interactive.
-
-
Bruno Lopes authored
Following 93722e81. I forgot adding into the list
-
Jacob Boerema authored
-
Bruno Lopes authored
This commit is mostly a little cleanup: - Reduce redundancy in Local compatibility layer regarding build commands, which partily reverts !1171 regarding buggy "ninja && ninja install" - Reduce redundancy of some variables (MSYS_PREFIX and GIMP_DISTRIB) - Remove manual QOI install since MSYS2 granted a exception in the win32 drop This commit also reverts 7cca69cd, a fix from the autotools era that isn't actually needed according to my tests in CI.
-
- Apr 26, 2024
-
-
-
-
-
-
-
-
-
Jacob Boerema authored
Copied over from the original separate work in: https://gitlab.gnome.org/Wormnest/gimp-file-plugin-tests After that further improved and changed and added more file format tests. Added meson.build files to integrate it in our build, but we do not install it for releases.
-
-
Jordi Mas authored
-
Alx Sa authored
Should resolve #11392 In dfb26f37, the NDE filters in the copied image are retrieved with gimp_image_get_layer_iter (). This works fine for single layer images or when all the layers are copied at once. However, if a subset is copied then the filters are always copied starting from the top level of the image. This can result in an incorrect filter being copied to the wrong layer. To fix this, we get the filters from the provided drawables list instead. This matches the number of layers in the copied image exactly, since it was used to create the copied image.
-
- Apr 25, 2024
-
-
-
Bruno Lopes authored
This regression was added by c064148a and it's similar to fb7a9954. Now, that we are using 'interruptible: false' in custom rules, this is probably fixed. Also, organize a bit better some pipelines with official GitLab .yml wizardy. I was hesitating to use "<<: *" since this creates a new layer of complexity, but this was the better way and the trick have a distinct marking by the way.
-
Anders Jonsson authored
-
-
Alx Sa authored
-
-
-
-
Alx Sa authored
-
This benefits script authors and testers of ScriptFu. Now a call to (display "foo") in a plugin goes to the terminal where GIMP started. Whether interactive or in batch mode. Make TS errors go to an error port instead of the output port. Tool plugins: Console, Eval, Server get error messages from the error port. TextConsole not changed. Tools behave per new doc "ScriptFu Tools" at dev web site. Driveby fix of SF Server: send whole message instead of byte by byte. Driveby comments and more semantic checking of set-output-port in TS. Add test plugin test-display.scm
-
Alx Sa authored
In addition, this restores the palette options for HGT import that were accidentally removed from 2.10. Mnemonics were also added to parameters which were missing them earlier.
-
- Apr 24, 2024
-
-
Jehan authored
As noticd by Bruno, the meson port is inconsistent with our 2.10 autotools build here too (and therefore our data path standards). Fixing.
-
Jehan authored
-
Bruno Lopes authored
It's not obvious (when browsing in the repo) where the macOS files are. Now, that we have one folder per OS, this became desirable for clarity.
-
-
Jehan authored
Hopefully now the CI jobs can run?!
-
-
Anders Jonsson authored
-
Jehan authored
This should hopefully fix: > realpath: /Users/circleci/macports-gimp3-arm64/var/macports/build/_Users_circleci_project_ports_graphics_gimp3/gimp3/work/build/.GIMP3-build-config-: No such file or directory Though it's harder to verify because of the "Intel macOS resource brownouts" going on on CircleCI infra, and only x86_64 runners allowed me to SSH to them. But I think that's the right fix seeing the error.
-
Jehan authored
The preview widget is a bit stretched, though at least I fix the contents to be distorted (instead, the preview is fine but we've got black-filled parts around). I'm not focusing on it because anyway, I'm not sure either if the preview is that important, or (if it is) whether we should not just integrate it as part of GimpVectorLoadProcedureDialog, i.e. for every vector images.
-
-
Bruno Lopes authored
For our two "development" sub-stages, the expiration is as follows: The 'dependencies' stage artifacts continues to expire in 2 hours. Now, all 'gimp' ones expires in 2 days (to avoid time zone limbo). For "stage"/tests and "production"/dist, the expire time depends on the source of the CI pipeline. If the artifact is oriented to a 'short-span' source (e.g. MRs and commits), it expires in 2 days. If is oriented to a 'LONG-span' one (e.g. web, schedule), 8 days (we choose 8 to have a +1 day artifact just in case if something goes wrong in the weekly schedule day, which isn't rare actually).
-
Jehan authored
This happens in particular for in-build runs (or when using GIMP3_DIRECTORY environment variable on an empty directory). In any case, I don't see why we wouldn't try and create a directory which was configured for data storage.
-