When moving a floating layer or selection, we draw a solid
border around the object. However, we also let the "marching
ants" selection continue (if the user has it enabled). This slows
down performance when moving, especially on large selections.
This patch incorporates logic from the Selection tools into the
Edit Selection tool (which the Move Tool uses for translation).
It stores the user's "Show Selection" setting, sets it to FALSE
while moving the layer or selection, then restores it to its
prior value when the cursor is released.
This logic also extends to using Ctrl + Alt to drag a floating
selection out of a layer that already has a selection.
gimphistogram.c used its own custom MAX_N_COMPONENTS
define for the max value of its "n-components" property.
Since this value is the same as MAX_CHANNELS, it would be
good to use the global constant so the histogram limit automatically
updates when we added a new format with a larger number of components
such as CMYKA.
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.
