The bug is in fact in GTK. "image-missing" is supposed to never missing since
GTK embeds an icon as GResource. But it turns out that the code is buggy. So if
an icon is missing from GIMP theme, then system theme, then "icon-missing" icon
as well, GIMP crashes.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/3526
As a workaround for now, let's at least add our own "image-missing", at least in
our main themes (Color and Symbolic, not Legacy). This will make GIMP not
crashing at least by default when another icon is missing.
Of course a crash could still happen if one use Legacy or a third-party theme
and if their system theme doesn't contain "image-missing" as well, until GTK is
fixed.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
GTK docs is pretty clear:
> It is a programmer error to pass an invalid accelerator string. If you are
> unsure, check it with gtk_accelerator_parse() first.
So now we verify validity of accelerator strings before using shortcuts from
config files (which can be consider "human input" as the file can be modified).
A first attempt at fixing this was going through the idea of changing the
concept of radio actions, such as allowing an active action in an action group
to be called again. Or having some action in the radio group which can be called
but never set active.
But in fact, I just realized that these zoom actions are simply not meant to be
radio actions. They are not stateful actions, nor are they exhaustive.
I also updated the `other_scale` storage logic. Instead of updating it each time
the zoom changed (which was even broken in some cases, like when changing zoom
through another action), I simply save the last custom zoom value. This is the
one which is reused across calls. I don't think always resetting to the current
zoom value is very useful (if you call this dialog, it's not to zoom to the
current zoom!). Also there was some concept of flagging this stored zoom value
as "dirty" by making it negative, but this was never actually used, which makes
me believe that current logic was not the original intent anyway.
Saving the previous custom zoom explicitly set seems to be a good enough
behavior, so let's go with it.
Resolves#10072.
The current PSP palette loading code does not check if
the file's palette entry count value is below the limit
(G_MAXUNIT32 / 4 due to each color being 4 bytes long).
This patch adds this check and stops loading if the count
is larger than GIMP currently supports.
Resolves#10071.
When reading RLE compressed data, a buffer was allocated to 127 bytes.
However, it can potentially be used to read 128 bytes, leading to a
off-by-one vulnerability. This patch allocates 128 bytes to the buffer
to prevent this from occurring.
This fixes 2 issues:
1. gimp_scanner_parse_string() may fail, which here would indicate broken input.
If it does, the string variable would not be set, so we need to initialize it
to NULL, otherwise freeing it could crash GIMP.
2. The variables set by gimp_scanner_parse_string() must be freed.
While I was testing some fonts I had on my system which were named exactly the
same, I also realized that all their fields were identical (among the ones we
store at least), except for the hash obviously. While the hash is great to
differentiate fonts when we use exactly the same files, there are various
reasons where one could have the right font installed with a different hash
(e.g. a simple reason could be if it was stored in different font formats).
So I'm thinking that maybe we'll want to add more fields in the future (if there
are any more fields allowing to better discriminate among some fonts named
similarly). This commit will allow this version of GIMP to still work when
loading the future serialized fonts with new and unknown fields. The unknown
fields will be ignored but at least it will still do its best to find fonts with
the known fields. Therefore we won't have to bump the XCF format version if we
only add new fields.
Similarly this allows to add the fields in-between, reorder existing fields or
even remove some in the future if we realize something is really unneeded. It's
less a big deal than the ability to add new fields without bumping XCF version
though.
Rather than looping fully over the full list of fonts once more, and
re-computing a second time the same font similarity score (with the risk of
messing up the copy-paste), let's just store the indexes of "most similar" fonts
in the first loop, then only query and check the hash for these.
Resolves#8756 (along with !1065)
The system theme leaked due to the checkbox styling not being
defined for GtkTreeView checkboxes.
The background-image in particular overpowers other settings.
The normal checkbox styling is now specifically applied to
these checkboxes as well.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
Resolves#10015.
The border color of the menu checkboxes was not
specifically defined by the CSS stylesheet, causing
the boxes to appear invisible when unchecked in
certain system themes. This defines the border color
to the same as the menu text to ensure visibility.
Resolves#10007.
The menu separator color was not defined in the stylesheet,
so it could vary based on the system stylesheet.
It is now set to @stronger-border-color.
Resolves#10040.
A System Theme leak could cause a large border to be drawn around
the export options at the bottom of the Save Image dialogue.
This patch defines them specifically as 1px border with the
@strong-border-color CSS styling.
Resolves#10000.
The border around notebook headers was not specifically defined in
GIMP's CSS stylesheet, so if the system theme used a different color this
would also change. It has now been defined as @strong-border-color.
The existing CSS was also moved to the same area as the other notebook
header definitions.
Resolves#10020
For some reason, not having the border-radius CSS style set
in widgets inside scrollwindow viewports causes them to have
a giant black order if they're not a full height. This was previously
fixed for GtkGrids. This patch fixes it for GtkBoxes as well, such as
the Procedure Browser description area.
Per @Wormnest comment on ACB palette loading,
g_utf16_to_utf8 () now uses the string length rather than -1 to prevent malicious non-NULL terminated strings.
Jehan