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.
Resolves#12018
During the port to GimpProcedureDialog, we accidentally
inverted the set_sensitive () logic for using RLE and the
RGB format. RLE was being locked for indexed images while
the RGB format was being locked for RGB images.
This patch inverts the two conditions to fix the issue.
..with gimp_bilinear_rgb ().
This function takes in a double array of raw pixels,
a boolean to determine if the pixels have an alpha channel,
and a reference to return the final pixel to.
Resolves#10822
After improvements by Lloyd Konneker and Jehan,
Script-fu's implementation of GimpProcedureDialog retains
defaults for GimpResources.
This patch ports lava.scm to use the new API, and also switches
the default gradient to Incandescent.
gimp_brushes_popup() was triggering a popup allowing to change not only
the brush, but also the "paint mode", the opacity and the spacing. As
far as I could see, this was used nowhere for the paint mode and
opacity.
As for the spacing, it looks like gfig was indeed getting this data,
except that the GimpBrushSelect was disabling the effect on this scale
by setting change_brush_spacing to FALSE when calling
gimp_brush_factory_view_new(), and even setting this to TRUE, it was not
working fine anyway. Rather than debugging this, let's simplify the API.
Such settings seems like additional paint settings which don't have to
be in the brush selection. If someone wants people to also select an
opacity, spacing or paint mode, it would be much more efficient to add
separate plug-in arguments for these.
Additionally, I fix GimpBrushFactoryView not to show the spacing scale
when change_brush_spacing was set to FALSE anyway. This is just a bogus
widget then, which can only confuse people.
Also fixes the passing of the resource param definitions through PDB.
There was some weird assumption, with a comment, in commit 73733335c8
that this was unneeded, which meant that we were not able to properly
recreate the right param spec over the wire.
Jehan