Resolves#12034
Previously, we used the Filter Tool's drawable when updating an
existing filter. However, if the user has a different layer selected than
what the edited filter is attached to, the edited filter is always put at
the top of the filter stack.
This patch retrieves the drawable from the existing filter itself, rather
than assuming the filter tool's drawable is the same one.
GimpRGB replaced with gdouble arrays.
Note that some temporary intermediate
GimpRGBs objects were added, which will
be removed when map-object and
gimpoperationgradient are fully converted
in a separate commit.
When converting an image TRC (or a precision+TRC change), we used to
convert the profile to a linear (resp. sRGB TRC) variant or use the
builtin profile, which we'd set on the image.
Pippin is telling me that "it used to be that linear and non-linear
precision gave different results, rather than only about how things were
stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any
profile is linear anyway, disregarding the profile's TRC.
Furthermore, this way, we don't lose the original TRC in a non-linear ->
linear -> non-linear roundtrip and we simplify the code, which fixes
such problems as shown in #3495 as a side effect.
The code was perfectly working already, yet we were blocking the
non-interactive case only to stop automatic runs, such as generating
thumbnails. The chosen solution is not perfect either as it would break
on the odd case where a given raw data file's expected dimensions were
the default. Yet it's a start.
Fortunately I caught this one, because the string values of the
GimpChoice argument would have been part of the API and confusing bits
per pixel and per channel is not so good for a graphic program! 😅
Only places this was alright were the grayscale ones, with no alpha
(where there is only one channel, so bpc and bpp are the same). I
hesitated a lot of I should write BPC to be consistent with other args
or not. In the end, I stick to BPP there, since I find it somehow
clearer this way.
Luckily this doesn't break string freeze because there was no mention of
what the bit-sizes represent in the arg labels.
We check the width of the zoom label (if it exists) and use it to size the
combobox's entry field. Otherwise, we default to the existing formula.
Also removes Windows special-casing for PERCENT_SPACING constant,
as Pango now uses harfbuzz on Windows as well.
This patch temporarily reverts 02546da7,
due to performance issues with our use
of Babl. After 3.0, we'll try to improve
these operations so they can be more
color correct.
However, GimpRGB, GimpHSV, and GimpHSL are
replaced with double arrays.
There are certain operations where we're
not yet getting sufficient performance with
Babl. For these legacy operations, we'll
use the original GimpHSV/HSL conversions
internally. This will allow us to replace
them in the future without plug-in
developers relying on them.
The name for internal data may be localized. This is the case at least
for some dynamic gradients (Foreground to Background and others).
Nevertheless they have unique collection name. So let's simply rely on
this for internal data.
See point 2 in: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1830#note_2218014
I also change the standard alias fonts to also have unique collection
names. These seem to be the only other internal data which had no unique
collection until now, which is now fixed.
This ensures that the devs who follows Debian instructions at gimp-web-devel
can build a full-featured GIMP and maybe we have a full-featured AppImage.
- Simplify three functions into 'bund_usr' (similar to 'bundle' in Win script)
- Add 'wipe_usr' function (similar to 'clean' in Win script)
- Verbose the steps of AppImage making
- Log (go)appimagetool bundling of deps (not only the the .appimage making)
- Change AppRun to be more clear about our .appimage compatibility
This refactoring is not perfect but is good enough to anyone understand
how our AppImage is made just reading the script.
Alexander Shopov