Resolves#11897.
The crop tool currently doesn't constrain
to the top-left of the layer when the
"Allow growing" option is turned off and
"Selected layers only" is turned on.
Instead, it always constrains to 0, 0.
When we converted to multi-layer select,
we added a loop to check the boundaries
of all selected layers. In this loop, we use
separate variables to get the offset and
then get the min of it and the current
min_x and min_y. However, those values
are initialized to 0, so they will always be
smaller if the layer is inside the canvas.
To fix this, before the loop we check if
there are any selected layers. If so, we
get the offset of the first layer and set
min_x and min_y to that value rather than
0, 0.
...bump map settings.
Currently, the Lighting Effect's bump map options uses
the RGB values of transparent pixels as part of its map.
As the Bump map filter does not do this, this patch tries
to make it consistent by using associated alpha for the
bump map Babl format to fix this.
Resolves#11892.
The new_unit_dialog () now initializes the default GimpUnit
to NULL instead of GIMP_UNIT_PIXEL. So we need to update the
check to prevent it from running when the user cancels the dialogue.
First of all: sorry to all translators who started working on these new
strings!
We use CamelCase for our titles, and in particular "Plug-In" is
capitalized with 'I'.
Furthermore, let's use understandable titles like "Plug-In Example in C"
and not just "In C", because while the short title works OK in the menu,
it makes for very broken action names in non-contextual parts of the
software, such as the action search.
Note that we in fact have a concept of short label for actions since
commit 89772351c9. I added support for it to GEGL actions (cf. commit
6dc5f6792e), and to a few core actions (e.g. commit ea1205f094).
Unfortunately I don't think I added an API yet for short label in
plug-ins. Maybe I'll add it soon. But for now, if we have to have a
single label, it should be long, so that it works in every situation.
P.S.: not sure if it's useful to keep documentation strings just
repeating the title, but for now, let's leave them.
Resolves#11890.
The Selection Editor's "vectors" group was not renamed
to "paths" during the GimpPath API update. This caused it
to be registered to a non-existent group, thus crashing.
Since it will be distributed in a release.
Only translate the menu item and help.
Not translate dialog labels, they will only be read by plugin authors.
The old menu label was confusing to users.
Remove translatable strings having joke "goat" so translators not confused.
Move the goat plugins to the menu.
The items under the menu should all be example plugins.
The menu is in a release.
Test plugins should not be in this menu.
Test plugins should not ship in a stable release.
!!! Note that 2.10 does not ship with example plugins.
If we don't want 3.0 to ship stable build with example plugins,
then the meson.build for goat-exercises needs to change
and the menu removed entirely in menus/image-menu.ui.in.in.
Adds a checkbox in the Filter tool so that
users can choose to apply a filter
destructively or non-destructively.
Currently only layers can have NDE effects
so it's not shown for masks and other
drawables.
Additionally, filters are moved to the top
or the bottom of the filter stack depending on
the setting (as destructive filters are applied
directly to the layer while NDE filters are
put on the top by default).
This fixes 2 issues:
1. Since gimp_edit_cut() uses gimp_edit_copy(), it had the same error
message when no selected drawables were within the selection.
2. When there was a previously existing clipboard image, gimp_edit_cut()
could return it as though the cut succeded, even when it did not.
While other parts of the commits were fine, this specific change was
clearly me going too fast. This is the format for a printf() call.
Fixes:
> app/widgets/gimpimagepropview.c:461:50: warning: format ‘%a’ expects argument of type ‘double’, but argument 4 has type ‘const gchar *’ {aka ‘const char *’} [-Wformat=]
I had the case on my machine where `lua` was version 5.4.4 and the
lua-lgi test succeeded fine, but then the demo plug-in would fail to run
with the error message from #11876.
Let's parse the output of `lua -v` to detect the version ourselves and
therefore be able to output proper error messages for packagers not to
assume that the Lua interpreter they are using will work fine.
Ported from: 3772514155
Just to note, ALL the previous "Sync with..." commits were tested in flathub
and gnome-nightly flatpaks, and this actual one (and future ones will be) too.
Ekaterine Papava