In particular, on Windows, we get this error:
> ModuleNotFoundError: No module named 'fcntl'
But we don't care about this module there anyway. This is only for macOS
builds.
Tab was intentionally removed from the action entry to avoid overriding
its standard accessibility usage across the software, leaving the menu
item and shortcut editor showing no shortcut. This adds a cosmetic hint
in gimp_action_get_display_accels() to show 'Tab' without registering a
real accelerator.
There is no such thing from Freedesktop for macOS. What we
use (at packaging phase) is an AppleScript by Alex Samorukov
at build/macos/patches/xdg-email.
So, makes no sense having that warning on macOS since such
custom script does not exist anywhere to be found at build-time.
This will be an alternative way to fix#14236, without needing to have
every usage depend on another (which is messy and bug-prone because then
we have to follow the list of dependencies and see which was the last
use of gimp_exe, and with the risk of errors depending on which build
options are ON or OFF).
This fixes such errors:
> error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> for: /Users/Shared/work/GNOME/gimp/_build-x86_64/plug-ins/common/test-plug-ins/film/film (for architecture x86_64)
> option "-add_rpath /Users/Shared/work/GNOME/gimp/_build-x86_64/libgimpcolor" would duplicate path, file already
> has LC_RPATH for: /Users/Shared/work/GNOME/gimp/_build-x86_64/libgimpcolor
The problem especially occurs for our new build rule where we generate
the gimprc man page from within the build. In particular, it uses a
temporary config folder generated on the fly (with a random folder name)
and sets various environment variables such as GIMP3_SYSCONFDIR. So if
we use the runtime paths, our man page will be full of bogus paths.
In any case, for a man page, it just makes sense to use the real install
prefix. This of course assumes non-relocatable builds, and an
XDG-compliant installation (as it uses the $XDG_CONFIG_HOME variable),
but that was already what we were showing in the template man page, and
man pages are mostly for Linux, *BSD, etc. So that works fine.
This script is now also used for usage where we pipe directly the stdout
output to a file, e.g. now to create the gimprc man page. We don't want
to have INFO messages in there.
Previously, paths from Photoshop TIFF files were appended via
gimp_image_insert_path(..., -1), which caused the displayed order to be
reversed. This change preserves the original ordering while keeping the
'Working Path' as the last element.
Resolves#12791 (again)
After cleaning up and separating the filter pop-up code
from GimpItemTreeView to GimpDrawableTreeView-Filters,
we accidentally lost the checks that prevent deleting filters
that have not yet been applied (thus causing a crash).
This patch restores the checks for the filter to not be temporary
before you can delete it.
Resolves#16018
This patch extends a2c5d70c to also apply to the
"Fit Canvas to Layers" action. It prevents the non-rasterized
vector layer from being shifted out of place when the
canvas is resized.
Resolves#16045
This patch extends a2c5d70c to also apply to the Crop Tool.
It prevents the non-rasterized vector layer from being shifted
out of place when cropped.
Closes: #16038
This may be related to how our babl relocatable heuristics works
on Linux: depending on the process path, which is tricky on Snap,
specially for 3P plug-ins which have their own sandboxed processes.
Ideally, we should fix it on babl but this workaround if good enough.
(Modified by CmykStudent from balooii's original merge request)
When performing image-level operations (resize, crop, scale, flip,
rotate, arbitrary transform), paths referenced by non-rasterized vector
layers were being transformed twice:
1. Via the vector layer's overrides, which explicitly transforms
the referenced path to keep it in sync
2. Via the image-level queue that processes all paths independently
This patch adds a check for whether the layer has been rasterized.
If so, we bypass the vector layer's transform so the path is not
transformed a second time.
While we want to try with the last tagged release (babl 0.1.124), we
still need the CI to work with the latest code. So let's add one more
temporary fix.
...in Histogram Editor.
The 2.10 Colorcube Analysis plug-in took into
account the selection when displaying the colors.
The Histogram Editor itself does as well, but our
unique color count did not.
This patch adds a check in gimp_histogram_unique_colors ()
to see if there's an active selection in the image.
If so, we get its area and use that as the bounds in
gegl_buffer_iterator_new () instead of setting it to NULL.
When loading layer metadata from TIFF 'ImageSourceData' Tag, don't assume
'Layr' is the first 8BIM block. Iterate over 8BIM/MIB8 blocks, skip non
'Layr' blocks, and rewind 4 bytes before calling read_layer_block() so it
can read the length field as expected. Limit mask_layer_len to the
selected block (including padding).
… rename for babl.
As we are doing test build for the release, we are in this in-between
situation where GEGL has the newly named option, but not babl (because
we don't have a new babl release).
I don't know if we'll have a babl release by the time we'll get GIMP
3.2.2 out, but for now, let's use the old option name.
This commit will have to be reverted later, after we release.
Multichannel PSD images reuse their first channel as the
main grayscale "layer". Our PSD plug-in did not take this
into account, resulting in the channels being off-by-one and
mislabeled.
This patch prevents chn_a[0].data from being freed after
it is used to load the layer, and then resets the counts so that
it is reused as the first imported channel.
In fact, the previous commit was unneeded and we could have done without
reverting the old commit. On the other hand, a buffer using another
buffer as "source" may be nicer in memory.
But the previous commit alone was not right as group boundaries were
wrong. In fact, right now, we can see that group boundaries are computed
using only the children layers (except for pass-through of course), not
including any effects they might have. And the buffer passed to
gimp_drawable_set_buffer_full() was the projection's buffer itself — it
was shared, which was also why copying at setting time was wrong —, in
the case of a group layer. That means that when we translated to (0, 0)
offset, either we would have moved the render to the wrong place, or
moved the boundaries to the wrong place.
The offset needs to stay what it is, even when it's not (0, 0), for
group layers.
Another alternative fix would be instead to fix layer groups' boundaries
to encompass the full projection's render. But I just went with this
special-casing of group layers instead.
Part of it reverts commit 3a53e4743e.
Another part is a fix to the CRITICAL mentioned in this commit.
This being said, it's clearly not entirely right yet. The boundaries of
the layer when the filter is merged are not correct, which is especially
visible when trying to draw on this layer afterwards.
Also the layer group boundaries (when reproducing the steps in #16010)
are clearly wrong too.
