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).
