Since the COMMIT_SHA, we default to build with MacPorts which is more native.
But it is wise to not be overly reliant on it, since it tends to be very flaky,
and Mac platform have very restrictive hardware with software always changing.
(cherry picked from commit 5abb249d1d)
Leading to Heap Corruption
An integer overflow vulnerability has been identified in the PSP
(Paint Shop Pro) file parser of GIMP. The issue occurs in the
read_creator_block() function, where the Creator metadata block is
processed. Specifically, a 32-bit length value read from the file is
used directly for memory allocation without proper validation.
Trigger -> when length is set to 0xFFFFFFFF
To fix this, we check that using that length doesn't exceed the end
of the creator block. If it does, we return with an error message.
Let's force having the bash-completion dependency when we want to enable
the feature. Then clearly shows the feature state in the final setup
summary.
Otherwise the risk is that GIMP may not use the correct path on a given
system and a packager who wants this script to be installed may miss
that it is installed in the wrong directory.
Fixes:
> ../etc/meson.build:31:39: ERROR: dependency.get_variable got unknown keyword arguments "define_variable"
This went unseen because this was not run when bash-completion.pc was
absent but this broke on our flathub build.
This avoids using the python chosen by Meson's find_program(),
which is not the one from find_installation() and can not have GI.
(cherry picked from commit 61c078fa43)
This is a useful debugging function for developers. It is enough to hide
the menu by default on stable releases, I don't think we also need to
hide the CLI option. Developers don't know all these options by heart,
so we need to make them reasonably discoverable!
(cherry picked from commit 083360fac1)
In particular make it also work with the `gimp-console` and with all
symlink names.
Also rename the bash completion file using the full application version
so that it will be possible to install several such completion files
side by side.
(cherry picked from commit 24a69df9ab)
We use a GimpCellRenderToggle for the Fx icon
in the layer and channel docks. If you hover over it
when there's no filter, a square "checkbox" will appear
and give the impression you can click on it, even though
you currently can not.
This patch connects the "visible" property of the toggle to
the number of filters attached to the drawable, similar to
what we did for "active". This prevents the checkbox from
appearing, and will hopefully reduce user confusion.
(cherry picked from commit dd28bae44c)
...for dark mode.
The Navigation and Selection Editor
docks use GIMP_ICON_TEXTURE as their
default background when there's no
active image. On dark mode, this creates
large bright areas in the UI.
This patch removes the calls to
gimp_view_renderer_set_background ()
for these docks so the theme background
is used instead.
(cherry picked from commit cf41831a58)
Normally the error should not be NULL if file_open_layers() returns no
layers. But just in case, in order not to crash when we could avoid it,
let's double-check.
(cherry picked from commit 76a255caa1)
...in GimpRGB format.
Resolves#14754
GimpGrid properties are saved and loaded
in XCFs as GimpParasites. When we
converted from GimpRGB to GeglColor
for the fgcolor and bgcolor properties,
we caused those properties to be lost
when saving a 2.10 and below compatible
XCF in GIMP 3.0+.
This patch adds new
gimp_config_get_xcf_version () and
gimp_config_set_xcf_version () API to
libgimpconfig's interface. This allows us to
pass the intended XCF version to the
parasite serialization process, and save
as either GeglColor or GimpRGB compatible
formats based on that value.
(cherry picked from commit 5753ac75b4)
In INTERACTIVE or WITH_LAST_VALS modes, the arguments were replaced by
the latest values, which is typically not acceptable for this specific
plug-in. Even in interactive mode, we still want file descriptors to be
set explicitly, and used by the plug-in.
This fixes such error I had on terminal:
> (busy-dialog:193133): GLib-WARNING **: 20:34:43.692: ../glib/giounix.c:414Error while getting flags for FD: Bad file descriptor (9)
And the worst part was that it sometimes prevented the busy dialog from
quitting (though sometimes it still exited fine despite the wrong file
descriptors 🤷).
(cherry picked from commit 7374da53da)
Though the crash in #14139 won't hopefully happen again, thanks to my
previous commit, these additional assert may help in debugging if ever
it does again. Because truth is that even with partly-loaded fonts, this
was weird. If we had a GimpFont already, why did we fail to get a pango
font, or to query its file path through fontconfig?
(cherry picked from commit 326358a76a)
Setting a step/page size of less than one for a spin scale bound to an
integer property does not make sense. Similarly the number of decimal
digits shown can be set to 0.
(cherry picked from commit e735054347)
This was happening when trying to load a file before fonts were fully
loaded, which may happen when loading while starting GIMP (either from
CLI, or from a file browser, etc.), or simply just after start for
people with a lot of fonts, whose font loading may take a long time as
background task.
Note that I didn't manage to reproduce properly because from reports, it
seems like the problem appears where some fonts may be only partly
loaded so gimp_font_get_hash() fails to load the font and get a hash. I
never managed to trigger such a case and no reporters answered my call
for testing of debug builds.
As a consequence, I'll just assume that simply waiting for all fonts to
be loaded before starting to load images would work out.
Note that the crash was not happening when text layers were using the
older syntax (pre-XCF 19) of text layer data, since it was not storing
any font hash, which means that we were not trying to compare hashes. It
would also not crash if fonts were not fully loaded yet, but we didn't
have any weird intermediate state where fonts appeared in the list yet
their file were not hashable (cf. what I failed to reproduce, as
explained in previous paragraph). But both these cases were not ideal
either anyway because then we could load the XCF apparently OK… except
that the correct fonts would not be associated to the related text
layers (hence as soon as you start to edit said texts, the rendering
would break). So we should wait for fonts to be loaded, and that was a
bug even when you can't reproduce the crash.
When starting GIMP without loading an image, or simply when fonts are
loaded quickly enough, it won't make any difference. So it should not
make startup any slower for most common use cases and installations.
(cherry picked from commit bf6fcac0a9)
These functions should not be for the PDB only. The core will soon need
these too (e.g. to load resources linked from a XCF file).
So gimp_pdb_get_data_factory() is moved to gimp_get_data_factory() in
Gimp class. And gimp_pdb_get_data_factory_item() is moved to
gimp_data_factory_get_data() in GimpDataFactory class.
(cherry picked from commit 41a464cb9a)
Even if we may have to wait for some feature, we may not want to freeze
the whole GUI. And this would also avoid the dreaded popup dialog from
the system which makes it look like the application is broken.
Finally in an upcoming commit, it will prevent the interface from not
being presented at all when loading images at startup (while fonts are
not loaded yet).
(cherry picked from commit 9f18afd2b6)
...if layers won't be resized.
This patch adds code to check if the
"Resize layers" option is set to None and
"Resize Text Layers" is turned off. If so,
then the "Fill With" combobox is not
needed and will be set to insensitive to
reduce confusion. Otherwise, the fill combo
is set to enabled.
(cherry picked from commit 897ffd5702)
I can't reproduce this issue, because when I set a fake font file as a
broken symlink, or a file without read access, it is simply not returned
as part of my font list to start with.
But from the issue discussion and traces, this should be the right fix.
(cherry picked from commit 98bd0d16fe)
… input devices.
Per Carlos' advice on gtk#7534, I wait for us to get a focus, since the
pad devices are only created at that point.
Note that this is a Wayland-only issue, but since it doesn't matter too
much that input devices are not initialized before we have a focused GUI
anyway, let's make this simpler.
At the earliest, the splash focus can announce a focus, but since it is
possible to start GIMP without the splash, display shells will also
possibly announce the first focus (there will always be a display shell
focusing at some point for any GUI GIMP!).
(cherry picked from commit d92c237a17)
This was happening in multiple cases, such as undoing a "Rasterize
filters" action, but also with a "Layer to Image Size" being undone, and
probably any other undo cases.
In particular here the culprit was that upon undoing, we were setting
the GimpApplicator's "gimp:compose-crop" node, while it was a "gegl:nop"
before. We must be careful not to set a crop unexpectedly when the node
was not set already, explicitly.
(cherry picked from commit 0157a9581e)
Checking for valid font files thourgh harfbuzz or freetype (as it's done currently)
is slow, to speed up font loading a but, a less robust but faster check is done, which
is just reading and checking the first 4 bytes of every font file.
(cherry picked from commit c0e5107eee)
