The markdown triple-quote (```) has to be on its own at the start of a
newline. Schumaml was telling me that too many reporters would paste
just after some text, which would therefore break the markdown syntax.
Instead let's add 3 newlines before the triple-quote, so that even
people who would not hit the "Copy Bug Information" button (but instead
select and copy) have a hint that these newlines are made on purpose.
Also add a comment (which is discarded by Gitlab) to make this even more
obvious.
Then even when pasting just after some text on the same line, the
triple-quote will end up on its own line.
(cherry picked from commit d3105e5c72)
… the container.
There was this weird case which we somehow could only reproduce on
Aryeom's computer/build, not mine, with the same code and reproduction
steps (reproducible at will on her build only). Basically when drag'n
dropping a duplicated layer inside a collapsed layer group, the
row-expanded handler would try to select the moved layer before it is
actually inserted. This would end up into crash-happy code.
I'm still unsure of why the order of operation is different here, but
anyway what is for sure is that the `inserting_item` boolean flag was
not protecting much. It's not like it's an actual mutex and anyway this
is not multi-threaded code either so this flag was mostly useless (which
is why we were crashing). Instead let's actually look if the item is in
the container or not.
GIF export was not taking into account that there can be
both grayscale layers with and without alpha in an image.
We make sure that the GEGL buffer knows the type of
drawable for the current layer.
(cherry picked from commit 3b3ab0aa11)
# Conflicts:
# plug-ins/common/file-gif-save.c
Similar to previous plug-in but only for autotools. Separated in its own
commit for easy cherry-picking to `gimp-2-10` branch.
(cherry picked from commit a4a6ac59e0)
Exporting to psd could result in very large files which often failed to
load in both GIMP and PS when a group layer with a layer mask
was present.
Reported on our IRC channel with a sample xcf which made it
possible to figure out the problem.
(cherry picked from commit 8fdeaddbe7)
So far all dds images were loaded as 8 bit per channel which makes
sense for most but not all dds formats.
This commit implements loading in 16 bit for "L16" - a 16 bit
luminance channel.
In addition to that we improve security a bit by not assuming
that L16 is the only left over case but instead explicitly
checking the correct value of rmask for L16.
For other cases we now set an error with enough details
to identify the type of DDS image that needs extra
handling.
(cherry picked from commit fe228a6f6f)
# Conflicts:
# plug-ins/file-dds/ddsread.c
Let's increase the default size of the metadata viewer a bit.
Ideally we would add some logic to determine the width of
the first column since that one currently depends on the
length of the longest tag. However for now this change
will be enough for most cases.
(cherry picked from commit 165b50abcc)
The round corners script was assuming that the drawable always
was a layer, which is incorrect when a layer mask is selected.
We fix this by always requesting the active layer instead of
active drawable.
We also enable this script for RGB and GRAY with alpha
channel. Although it might not always make sense to
use this script when an alpha channel is present, there
can be use cases where it is perfectly fine.
So let the designer decide if this script is suited or not
instead of GIMP making that judgement.
(cherry picked from commit ed35579861)
# Conflicts:
# plug-ins/script-fu/scripts/round-corners.scm
Closes: GNOME/gimp#541
Reviewer note: thanks to Stanislav Grinkov for cleaning up and reworking
a bit the patch, such as renaming the procedure to dir-make, as per
Kevin Cozens' review.
(cherry picked from commit 11906fa82c)
Removing useless condition, add a g_return_if_fail() assertion for the
only (impossible unless bug) case which we don't expect. Also set
default mindist to G_MAXLONG instead of a magic number (which was ok now
but might become a problem if some day colormap allowed more than 16-bit
per channel colors).
Finally break when we reach a distance of 0 since we won't get lower
anyway, so better stop early.
Thanks to Rafał Mikrut and Øyvind Kolås for code commenting.
(cherry picked from commit d6dac25579)
We cannot just compare the drawable format with the model-type specs of
the color model. We need to include the space now.
In my case, some random screenshot converted to gray then indexed would
assert because the format is "Y' u8-space-gray-sRGB" (or for layers with
alpha: "Y'A u8-space-gray-sRGB"), hence indexed conversion failed and
ended up dark.
(cherry picked from commit c0e605ef96)
Looking at the documentation it is indeed red that should go
in the lowest bits and blue in the highest bits so just
reverse our code for red and blue.
We also update the version of our GIMP DDS plug-in,
this way we can catch and correct RGB10A2 images
written by older versions of our plug-in and correct
them.
(cherry picked from commit cad6273fed)
# Conflicts:
# plug-ins/file-dds/dds.h
With my previous commit, I improved the search action display and search
algorithm (which was returning wrong results), but we had lost showing
the non-sensitive reason in menu item tooltips. This fixes it, by
actually appending the reason, but only in the end, on the GtkWidget
tooltip (not in the action's tooltip itself).
(cherry picked from commit 13a02aea23)
Fixes:
> Calling error for procedure 'gimp-brush-get-pixels':
> Brush 'Circle (03)' not found
The data/brushes/Circle-3.vbr brush doesn't exist since commit
7aa12175a4 in 2012 as far as I can see.
(cherry picked from commit 65e10faf50)
… to GIMP not text layer rendering in image
Patch was merged n Cairo today, wouhou!
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
If not mistaken, the fix should then appear in Cairo 1.17.6 or 1.18.0
(whatever comes next). As we are obviously not going to bump the Cairo
dependency so early, let's just add the patch, at the very least to be
used for our official builds. Also this way, we won't forget about this
issue in the future when we need to bump Cairo.
(cherry picked from commit 5f61d84570)
This is the same as what we did for #5357
but in the reverse situation. The reason
for not doing the same at that time was
because I wasn't sure if that was valid
in all cases.
Looking at the documentation it does seem
to be the right solution and is working for
the supplied example image.
(cherry picked from commit 48ff5313c3)
# Conflicts:
# plug-ins/file-dds/ddsread.c
… Cintiq 16).
Adding the patch provided by Knuckx. Note that the GTK3 variant of the
patch is already merged to gtk-3-24 branch and published since GTK
3.24.28. Nevertheless since the contributor also provided a GTK2
variant, it would be a bit of a waste to let it go down the drain,
wouldn't it?
So let's try and use it in our GIMP 2.10.x packages for Windows.
