Try proxy bindings before the IM context. On macOS and Windows,
the IM context consumes Alt+key events (Option produces special
characters on macOS; Alt triggers alt-codes on Windows), so
bindings such as Alt+Plus/Minus (size) and Alt+arrows
(baseline/kerning) would never be reached otherwise.
eec9d512 did not block calls to
gimp_drawable_filters_editor_visible_all_toggled () when
updating the "All Visible" toggle button in
gimp_drawable_filters_editor_set_sensitive (). This resulted
in unexpected visibility changes in some combinations of
filters being turned on and off.
This patch adds the blocking calls around the call to
gtk_toggle_button_set_active () to keep this consistent.
This patch makes it so that you can click the preview for
Original and Rotated images in the Metadata Rotation Import Dialog,
and have it open the image rotated as shown in the preview.
This supplements the existing button options, and matches how other
software works.
When hovering over the images, the cursor turns into a pointer to
further suggest it is clickable.
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.
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.
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.
(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.
...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.
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.
The Path Import dialog has an option to choose whether
the imported paths scale to match the dimensions of the
image or not. While this variable guards scaling the paths
themselves, it did not prevent the viewbox from being scaled
Thus, the paths always appeared to be scaled.
This patch adds a check for the scale parameter in parse_svg_viewbox ()
and conditionally scales the viewbox based on user input.
This was tested with both in-house MacPorts, in-house HomeBrew and
legacy CircleCI builds and I confirmed it works (it is needed only
by the in-house MacPorts builds).
My use case was loading a 0-bytes swatches palette. This would crash
GIMP. And so would likely a zip archive suffixed .swatches with no .json
file in it, or a corrupted archive which would return ARCHIVE_FATAL when
attempting to read entries…
This patch fixes these edge cases. It also better handle the various
return values of libarchive. E.g. we should not abandon reading when we
get ARCHIVE_RETRY; and ARCHIVE_WARN is also a success case (despite
having some warning message).
Finally I break from the archive reading loop at the first JSON file, so
that we don't leak memory if there are several JSON file. It does raise
the question if this palette format allows such use case (several
palettes in a single .swatches archive).
The sample in the description of !2613 was failing to load with a bunch
of criticals. That was because when profiles == NULL, we would call
json_reader_end_member() while we never called the associated
json_reader_read_member(). Inverting the order of tests fix this.
