… 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!).
tar doesn't compress on its own, it's just a container format. It
doesn't look like these 2 files are actually used otherwise, apart from
being log artifacts (at least I couldn't find any script decompressing
these).
This is an attempt to reduce size of artifacts on deps-flatpak because
CI complains with a "Request Entity Too Large" error.
This reverts commit fdb4111e3f.
I did not reverted before because seemed that GNOME guys bumped the
GitLab log limit but we just confirmed that it is still there.
This is a complementary commit to my previous one. Now let's try to
detect cycling links when importing images as link layers. It's much
friendlier this way, with early errors (rather than let people load
links with cycles, then save a XCF, and finally get an error message at
next XCF load).
This is part of the fix for #14985, only relative to loading. It assumes
that we already have a XCF with cycling in it and will cleanly load it
(instead of forever cycling). For this to happen, I split a bit some of
the header loading code in separate functions to quickly load the header
of every link recursively until we either reach a parent file (i.e. a
cycle was discovered) or we read them all. It means we don't discover
any level of cycling (however many successive links end up to a previous
file!)
File identity will follow symbolic links as well as verify hard links.
When a cycling link is discovered, the link is downgraded to a raster
layer (showing the last render of this layer).
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.
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!
If the config object is NULL, we later face crashes! My guess is that we
had only been testing editing custom ops, but not creating them from
public API!
