Instead of blocking various drawable-editing tools to work on vector or
link layers, per tool (as in commits 38c379cd92 or 36330a271a), let's
have a more generic logic in GimpTool. We will now block the tool
initialization early when it's destructive and tries to work on link or
vector layers.
By default, all tools are set as being destructive, but we can override
this per-class by setting the class' is_destructive flag. For instance,
text and path tools, or the Zoom or Color picker tools, etc. are
non-destructive.
Filter tools also are non-destructive (they may be destructive, but have
their internal code to disable this path on these types of layers).
Source tools are special-cased because we may allow them to be
initialized on a link/vector layer as sources. For this special-case, I
make a second check on gimp_tool_button_press().
In the page selector the translation for "All n pages selected"
was always used, even if all pages weren't selected. This was
caused by the same singular msgid being used in multiple places
with different msgid_plural.
These were then all smashed into a single translation. Replace one
of the singular msgid:s to avoid this. This string is never shown
since the n_selected == 1 case is already covered earlier in the
code.
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
… pass-through group layer.
Because of the strength-reduce pass-through to normal mode, we had case
when the effective layer mode of a pass-through group ended up to
Normal, which may shrink the effective bounding box.
Note that getting rid of the GimpGroupLayer's get_effective_mode()
(gimp_group_layer_get_effective_mode()) implementation was also fixing
this issue. I did hesitate a lot because it is also simplifying the code
a lot. But I was also wary about getting rid of the optimization
previously made by Ell (see commit fa9a023c270; note that I haven't
actually tested how efficient this optimization is).
This seems like a good compromise.
On empty pass-through groups, it was returning a 1×1 area, which
triggered effects with X/Y distance arguments to have no set min/max
values. For instance, a gaussian blue's X/Y scale widgets end up showing
a [0, 1.5] range, making it very impractical to set higher values.
… impossible to use them like adjustment layers without additional step.
Even without the "adjustment layer" look-alike use case, this is wrong,
because an effect on an adjustment layer will be only applied on the
area contained in child layers, whereas by definition, a pass-through
layer would use the below render as input, and therefore its output
could be bigger than its child layers box.
I could find commit aa9ae1c65c as a culprit commit, and reverting it
would in fact also fix this issue, though by doing this, we'd regress on
the issue #4634 (I tested with one of the contributed XCF and can indeed
reproduce the bug).
Instead I return the unioned bounding box of the node, and of the
computed one. I do not feel like it's optimal, but this feels like a
complicated issue. It looks to me like there might be another deeper
issue in how both these bounding boxes are computed (not optimally!).
In any case, it also makes empty pass-through groups now usable to apply
directly an effect on the whole below render, as a side effect.
When the Exif metadata comment after our adjusting was NULL, we got a
critical:
CRITICAL **: 14:09:21.853: gboolean gexiv2_metadata_set_exif_tag_string
(GExiv2Metadata *, const gchar *, const gchar *, GError **):
assertion 'value != NULL' failed
Instead of trying to set the tag with a NULL value, remove the (now
empty) tag, if there was any.
See issue #15032
In gimp_image_metadata_interpret_comment (), it's
possible to set the variable comment to NULL.
We then have a later if statement that checks if index 0
of "comment" is \0 - if comment is NULL when this
check occurs, we cause a crash.
This patch adds a check to confirm comment is not NULL
before running this if statement.
Resolves#15001
In the MyPaint Brushes v2 port (ea8b9dc1),
I implemented a cursor_update () function from the
parent class. However, I did not call the parent's
version of the function afterwards, so the MyPaint
Brush cursor was not being redrawn. This patch
adds the call to fix the cursor display issue.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
