The INFO message "a stray image seems to have been left around by a
plug-in" was annoying when GIMP is run non-interactively, and when it
was about images open from command lines. Typically this message would
be visible on our CI when the various gimp-data scripts would fail. This
could only confuse script developers.
The fact is that while a plug-in (or batch script) should definitely
clean after itself by deleting images it created (unless it gave it a
display, in which case ownership is moved to the GUI), it is absolutely
expected that images opened through the command line would still exist
at exit.
It is not a fix yet for #14681 but would provide nicer and earlier error
when a call to gimp_temp_file() fails, which may happen in some cases.
E.g. if the temp directory doesn't exist and we fail to create it.
As a test, if I delete /tmp/gimp/3.2/ and give root ownership to
/tmp/gimp/, now the error when opening our gimp-splash.xcf.xz is:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating directory /tmp/gimp/3.2: Permission denied
This is a further improvement, for the specific case which appeared on
issue #16160. Basically here for the specific case when we have
permission issues, or other similar issues where we fail to either load
the input image, or export to the temporary file, we would get more
explicit error messages. And this would also show in the stderr output
of the in-build-gimp.py script.
In particular, when reproducing #16160 permission issue, the build logs
now contain this error:
GIMP-Error: Opening '/path/to/gimp/gimp-data/images/gimp-splash.xcf.xz' failed: Error creating temporary file '/tmp/gimp/3.2/gimp-temp-1719540.xcf': Permission denied
This should better help diagnose similar issues in the future.
… even when we have no display.
gimp_message() supports a NULL handler object and we get proper
GIMP-Error message printed on stderr, e.g. when GIMP is run from the
build system.
We want as much info as possible when debugging our build scripts.
This is part of fixes to improve situations such as seen in #16160.
Resolves#14583
If the user chooses to vectorize PDF layers with single colors,
get_layer_color () is run to use histograms to determine if they
are indeed a single color. gimp_drawable_histogram () is used to
get the RGB values as averages. This function returns values in the
0...255 range for 8-bit images and 0.0...1.0 range for all the
other precisions.
However, we did not properly normalize the values, resulting in
blown-out white layers when exporting 8-bit images. This patch
checks if the image is 8-bit and divides all values by 255.0f in
that case.
It also checks if the image is in linear precision or not, as
gegl_color_set_rgba () assumes the color values are linear. If not,
gegl_color_set_pixel () is used instead. Finally, the color mode
checks are made a bit more robust in preparation for future color
modes like CMYK.
We were using VCPKG_DEFAULT_TRIPLET, which makes impossible to
use x64-windows-release triplet since vcpkg starts to crosscompile
(even on the same arch). Let's fix this by using the right env var.
In GIMP 2.10, the PDB call
gimp-context-set-line-width-unit allowed
for Pixels to be set as a unit. In 3.0, we
changed GimpUnit to be a proper object
and gave it options to allow pixels or not.
The default setting is 'no pixels allowed',
which caused the unchanged
gimp-context-set-line-width-unit parameter
to no longer accept pixels as a unit.
This patch adds `allow_pixel => 1` to the
PDB set-up for setting units to fix this
oversight.
Resolves#16019
The Edit -> Fill with... options did not respect if
layers could not be filled (such as linked layers or
multiple selected layers with some layers being
pixel locked). This patch adds checks instead of
unconditionally filling those layers.
It also adds the text & vector specific fills from 916cf84e
to keep this action consistent.
This adds aalib, gi-docgen, libheif, libmng and vala.
The homebrew list was originally minified since all-deps-uni was
ported from the treatment of vcpkg on build/windows all-deps-uni.
But since on homebrew we don't build anything, let's install them.
This also adds to the list deps already installed recursively.
Resolves#16151
The original implementation mixed up the variable that
needed to be used for boundary checks - it should be
"estimated_size" and not "flags". This patch fixes the issue
to prevent a buffer overflow.
I noticed this yesterday, especially through gimp_image_get_active_array()
and gimp_image_get_visible_array() which are looping through
MAX_CHANNELS, hence assuming the passed components arrays are of
sufficient size. I could have just added some comment to document that
we must be careful when calling this, but this is currently completely
unused code. So I prefer to just clean it out.
If we need something like this in the future, we can just do it better.
Resolves#16150
Per Bronson Yen, it's possible to create a transparent chunk
that's larger than 256 index values. In that case, the trans[]
array will overflow since we initialize it to 256 indexes.
This patch adds a check to make sure the iterator used for the
transparency for loop does not exceed the array size even if
the chunk size does.
Previously, when using shortcuts to increase or decrease the font size of
the selected text, the size would jump to 0. This behavior occurred because,
if the text did not yet have a font tag, the initial font size was evaluated as 0.
This commit ensures that the text tool's default font size is used when
no font tag is present. This prevents the font size from jumping to 0 the
first time the shortcuts are used.
Fixes when compiling:
> error: variable length array ‘mask_row_buf’ is used
With this and previous commit, we can now compile with C++ flags
-Werror=vla and get no build failures.
Fixing in the gimp-macos-inhouse: [arm64] job:
> ../app/core/gimpbrush-transform.cc:869:17: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
Also adding some asserts in some places where we rely on the
MAX_CHANNELS constant so that we will quickly detect if this variable
needs to be further bumped in the future (especially as we will add
CMYK+ support as backend format).
