... for applying the global style.
Last commit *might* have fixed the need to use "*" instead of
"GtkWidget", although it's hard to tell -- nothing seems to be
obviously wrong, anyway. Let's just try restoring this, and see if
anything breaks.
In the gtkrc files of the Dark and Light themes, replace a bunch of
"widget" selectors with "widget_class" selectors, which is what
they really should be (they should probably also use angle-bracket
notation for classes, but as long as it works...) This allows the
different styles to be merged correctly, and fixes the active layer
name color (more generally, the text color of selected rows of
focused tree-views inside dockables.) The Gray theme seems to be
double-broken in such a way that "fixing" it causes it to do the
"wrong" thing... I'm not touching that :)
My previous commit answers the forever question "do we want to require
this?" which was in comments and can now be removed.
We don't need to actually require this operation for running GIMP, as it
runs fine without. Just testing in configure is enough of a warning for
the missing feature.
(cherry picked from commit 97247f41ea)
This is a runtime dependency. If absent, we simply won't have access to
the alternative Matting Levin engine in the foreground selection tool.
If we don't add a test in configure, this may be easily forgotten. I
created the `gegl --exists` feature specifically for this kind of
checks, so let's check operation existence.
(cherry picked from commit 9560a653c5)
After Dirk Farin had another look in the specs, it turns out that "mif1"
is actually allowed as major brand for HEIF. Also adding "msf1" which is
the equivalent for image sequences.
(cherry picked from commit 64b00b5c7f)
Just looking for "ftyp" would also match other ISOBMFF files (.mov or
.mp4 files for instance). These are the possible 4-byte "brand" code
which can follow "ftyp", as listed by Dirk Farin from libheif.
I add the "mif1" brand, as I encountered some files using this magic
(even though this should normally not be valid apparently, yet the file
loaded fine in GIMP).
This is not perfect as the standard allows potentially very big box
headers, in which case 8 bytes (the "largesize" slot) may be inserted
between "ftyp" and the brand, as I understand it. But this is actually
unlikely enough to probably never happen (the compatible brands list
would have to be huuuge, as it looks like this is the only extendable
part in a ftyp box). So let's assume this just never happens.
See also: https://github.com/strukturag/libheif/issues/83
(cherry picked from commit 4ad3993eca)
Nicknames on IRC/gitlab are hard, even more when they change depending
on the media! I realize we are regularly asking them or unsure of who to
contact (for instance here for releases). Let's associate each package
with its current maintainer to make it easy to contact the right person
to prepare our official packages before a release.
(cherry picked from commit dc9a30446b)
Adding a magic number for HEIC/HEIF, which would allow to discard
obvious non-HEIC images even with the wrong extension.
Note: it looks like this magic number would also match more generically
other ISO base media file format (ISOBMFF) formats, like .mov or .mp4
files. I am enquiring for better magic but for now, this is better than
nothing.
(cherry picked from commit d738d2f645)
performance-log-viewer.py is a viewer for GIMP performance logs.
The viewer is made up of two parts: a sample-selection area at the
top, and an information area at the bottom.
The sample-selection area visualizes the sampled variables and
markers using a simultaneous set of plots, and displays the
currently selected samples. Samples can be selected directly
through the sample-selection area, or by other means, such as
searching for all samples satisfying a certain condition, or
containing a certain function.
The information area shows global information stored in the log, as
well as information specific to the currently selected samples,
including variable listing and statistics, full backtrace, and
profile/call-graph information.
Note that performance-log-viewer.py takes its input from STDIN,
like the rest of the performance-log tools, and is therefore
suitable for use as part of a pipeline. For standalone use, the
performance-log-viewer driver is also included, which takes the log
file as a command-line argument, and processes it through an
appropriate pipeline before feeding it to the viewer.
(cherry picked from commit 3601c9189b)
... which statistically deduces the correct thread states based on
backtrace address frequency, fixing local inaccuracies.
(cherry picked from commit 7e186f3e5d)
In addition to the verbose GIMP version, include in performance
logs the values of all environment variables beginning with BABL_,
GEGL_, or GIMP_, and of all the GEGL config options.
(cherry picked from commit 2c6b5c371e)
