This issue was raised by Anders in #15152 and it was a mean one, because
it really looked like file-ani-export was crashing inside
_gimp_procedure_config_end_export() (so after its main run function),
but somehow only when being called from another plug-in (in particular
here, from the file-compressor plug-in). So it looked like a bug
somewhere in libgimp.
It turned out to be a "simple" memory corruption which was not
immediately showing its consequences.
(cherry picked from commit 381fad7253)
Resolves#13598
Applies the same logic designed by Jehan
in f78a0629 to the gimp_drawable_get_sub_thumbnail
function.
This allows GimpZoomPreview and
GimpDrawablePreview in older
plug-ins to show correct previews for
images that are larger than 8-bit.
(cherry picked from commit b420a7738c)
This bug had several causes:
* gimp_drawable_get_thumbnail_data() is pretty crappy as it just returns
dimensions and bpp. You get no real format information.
* When using it to create a GdkPixbuf, which seems like the most common
usage, only sRGB (with or without alpha) in 8-bit is supported by
GdkPixbuf.
So I'm just making sure that private _gimp_drawable_thumbnail() PDB proc
is only returning 8-bit sRGB(A) data. For thumbnailing, this is probably
fine anyway.
Fixes when calling gimp_drawable_get_thumbnail() on an item from a
high-bit depth image:
> LibGimp-CRITICAL **: 20:12:21.028: file ../../../../../../../dev/src/gimp/libgimp/gimppixbuf.c: line 112 (_gimp_pixbuf_from_data): should not be reached
(cherry picked from commit f78a062950)
I'm looking at #14014. It's probably not the problem either, especially
as gimp_parasite_new() would return a NULL parasite anyway with an empty
name.
But better be thorough and output a sensible error as soon as possible
when loading a XCF.
(cherry picked from commit d320b85115)
gimp_image_set_simulation_intent() attachs a "image-simulation-intent"
parasite which means that it first detaches and frees the one which was
deserialized from the XCF. When calling gimp_parasite_get_name() on this
later on, we were working on a dangling pointer. It means that the fact
we didn't have crashes most of the time was the unexpected part, not the
crash itself!
Same for gimp_image_set_simulation_bpc() and "image-simulation-bpc"
parasite.
The fix is to swap the order of statements to first detach the parasite.
This reverts commit 7b023177a8 and reimplement it as a CRITICAL because
if this happens, a bug has occured. If so, we don't want to hide the
bug, we want to be warned of it so that we can investigate further.
Clearly it should simply not be possible to create a parasite with a
NULL name. First if we look at xcf_load_parasite(), we were already
returning early when the name was NULL. Also even the constructor
gimp_parasite_new() has an early check and will return NULL on a NULL or
empty name.
So the question is: how come we had a parasite with NULL name (if that
is really the problem)? I don't have the answer to this and it's
possible that this bug had already been fixed somehow. But in any case,
if it happens again, we'll want this CRITICAL to run.
Sometimes, probably due to a metadata corruption, a pasarite with a NULL
name can be present in the parasite list. This causes a crash when
trying to remove it, because `gimp_parasite_list_find` does not accept NULL
keys. This commit adds a check for NULL names in `gimp_parasite_list_remove`.
(cherry picked from commit 7b023177a8)
This one was happening very rarely, which made it hard to track, though
I think it would happen more frequently to people with a lot of fonts
(and therefore font loading would take a lot of time) since the
problematic situation occured when the thread callback
gimp_font_factory_load_async_callback() would run after the
corresponding tagged container was created in constructor
gimp_data_factory_view_constructor().
When this happened, the source and filtered containers were not
synchronized regarding their freeze count. And in particular, the
filtered container would have one less freeze and would try to thaw once
the thread callback ran and thaw the source container, which was
provoking the CRITICAL.
(cherry picked from commit 8f9b742b51)
Resolves#9324
In GTK3, a default "Search" is enabled by default in GtkTreeView.
While in most places we override this with our own search feature,
it was not explicitly set for the GtkTreeView in the GimpComponentEditor
in the Channel dockable. So, it defaulted to TRUE and created an
unnecessary pop-up whenever you typed after clicking a channel.
This patch calls gtk_tree_view_set_enable_search () and turns off
this default feature.
(cherry picked from commit cb552d3dc0)
Fixes https://gitlab.gnome.org/Teams/Translation/dz/-/issues/3
The plural form for po-python/dz.po causes a segfault when trying
to run the Python console, so change it to the plural form used
in the other Dzongkha files in GIMP.
(cherry picked from commit 9bf1152dd8)
As said in previous commit, this controller was removed as commit
76ddf4421c. Unfortunately we can't easily remove the full
(GimpControllerInfo) record, unless we were to redo or enhance the
migration code, because current code works line by line.
Nevertheless this change is enough to render the GimpControllerInfo
object invalid in a way where we can detect and clean it out (cf.
previous commit).
(cherry picked from commit a9dce982a6)
… controllerrc config file deserialization.
This is the first part to handle #13787 and not a bad idea by itself
per-se, since we remove one way to crash GIMP by creating an invalid
controllerrc file.
(cherry picked from commit 57f8e233f7)
… deserialize with a wrong or unknown type.
The error message in issue #13787 was about trying to deserialize a
GimpControllerMouse object as GimpControllerInfo's controller. Yet
GimpControllerMouse was removed with commit 76ddf4421c so this was
failing.
With this change, such error would be more explicit, with an error
saying:
> Unknown object type: GimpControllerMouse
… instead of:
> unexpected character ')', expecting string constant
(which was very confusing to the actual issue)
(cherry picked from commit 5831b7ddcb)
This URLs are useful when users want to see more information about
release notes. They are visible on software stores like GNOME Software
and software websites like Flathub.
(cherry picked from commit 0f07df00d9)
Resolves#15113
There is code in the Gradient Flare plug-in to prevent deleting
gradients when there is only one left. However, the flare count
was not being properly updated. Due to a stray unbounded IF
statement, "if (tmp->next == NULL)", the num_gflares variable
was only decremented if you deleted from the bottom of the list.
As a result, you could delete all the flares and cause the plug-in
to crash when it tried to render a non-existent flare.
This patch removes the stray IF statement and adds additional checks
to make sure dlg->gflare exists before trying to get a pointer from it.
(cherry picked from commit 3cb0eb2df5)
See: Infrastructure/gimp-web-devel#9
gitlab-mr.md was removed without replacement since the
package generation info is now on the MR template for
everyone's benefit (6245e4ee) and the test of the
text was mainly personal annotations.
(cherry picked from commit f771437242)
See: Infrastructure/gimp-web-devel#9
Except API-for-resources.md, which is ugly and
not linked in the README. And GIMP3-API-Changes,
which seems to be just a personal annotation.
(cherry picked from commit 13d3643ad7)
Resolves#14752
Our previous logic only worked for single-page PDFs.
If a multi-page PDF was exported, only the first layer
would have the background color set - the rest would
always be transparent regardless of user choice.
This patch moves the "fill background" logic deeper into
the layer drawing code, so that it is considered for each
layer rather than once at the beginning. It is also adjusted
for different situations, such as when the user wants group
layers to be combined.
(cherry picked from commit 6910945bd4)
Similarly to Flatpak's "add-extensions"."org.gimp.GIMP.Plugin"."version".
Otherwise, we would have broken Snap plugins on GIMP 4 which breaks API.
(cherry picked from commit ad2c3beded)
When non-interactive mode is requested (the -i command-line flag),
_and_ we've compiled the app with UI support enabled, allow `gimp`
to branch into the console-based version of the app -- equivalent to
running it using `gimp-console`.
This avoids GTK-related failures open a display when one is not
not available (for example, when running `gimp` within a container
or a VM without a graphical display).
(cherry picked from commit ea0574b86c)
