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.
As discussed in #11876, the interp files work fine on Linux (and other
platforms) too, and this allows to properly redirect to the working
interpreter found at configure time, without touching the scripts'
shebang.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/11876
For 3.0 we will support only Lua 5.1, since we need to figure out how
much of the Lua 5.1 API is compatible with newer versions (Lua minor
versions aren't like Python minor versions, there is API breakage so
plug-ins would be completely unreliable, this commit prevent this).
Also, change some files to not force luajit since it isn't mandatory.
As in f9df9805, adds SVG versions of GFig
custom icons and conditionally uses them if
have_vector_icons is enabled. If not, we
fall back to the original PNG icons.
Also resolves#10012 by adding white
outlines around the thin dark lines to
make them more visible in dark mode.
This is the pendant commit to the one I'm going to commit on the beta
branch for RC1. There in fact was a way to always use the
$XDG_CONFIG_HOME folder, unconditionally (and prevent the weird
inconsistencies of having config folder in .var for some flatpak
installations and in XDG folder for others).
See: https://github.com/flathub/org.gimp.GIMP/pull/287
Apparentely `makeappx` tool deletes empty folders and MSIX runs with
system paths read-only. So calling g_file_make_directory_with_parents()
is just not enough.
Therefore when opening font folders recursively for font parsing, let's
just ignore the specific error of non-existing folders.
This patch adds support for loading Sketchbook
TIFF layers.
Alias/Autodesk Sketchbook used metadata tags
to store information about layers. This is a
separate implementation compared to Adobe,
stored in TIFFTAG_ALIAS_LAYER_METADATA.
The first directory contains the image metadata
and the layers are stored in SubIFDs, using the
same metadata tag for layer-specific properties
such as opacity and visibility.
This is a followup of commit f2d47ee53a.
I realized that the window's size was too big for the case when there is
an image as well because the scale factor of 1.0 was hardcoded. We now
use the scale factor from the display the shell is displayed on.
Unlike the other bindings (Lua, JS, Vala) where we only have a demo
plug-in, we actually have a bunch of interesting and useful Python
plug-ins.
Furthermore, we are running several Python scripts through GIMP during
our build (to generate a few images), so pygobject becomes a build
dependency anyway, even if it may not be a run dependency with
-Dpython=disabled.
This all becomes a bit confusing and in fact handling this case (of not
installing Python plug-ins) seems like an annoyance while we lose good
core plug-ins. So let's just make Python plug-ins mandatory. It's not
like Python is very controversial these days, and AFAWK, it is available
on every platform out there.