GitLab

Fixes #1438

Currently editor pages have their page icon set to the one found for
the corresponding MIME type of the file.

While those icons are correctly shown under "Opened Pages" in the left
sidebar, they are only shown with the default text/plain MIME icon in the
frame header's Open Pages popover, so per-MIME type icon support is left
unfinished.

So this commit fixes it by changing from a binding of the icon-name
to a binding of the (g)icon, because the icon-name property is only a
shorthand to set the gicon, but icons at the end of the day are always
set in the (g)icon property even when setting icon-name. This is
especially important since ide_g_content_type_get_symbolic_icon gives a
GIcon, not an icon name. That's why editor pages were shown with the
text/plain MIME icon in the popover, as the icon was first set with
icon-name before setting it with the gicon associated with the file's
MIME type.

We can get into an infinite (albeit async via user-flow) state if the
downloads fail and pipeline reloads.

This only invalidates the pipeline if the task was successful.

Related #1430

This reverts commit a012c9ef.

This shouldn't have been changed, as object does not need to be related
to the object to be useful as a snippet.

g_task_is_valid additionally checks that the source object is correct.

We need these untouched so that running a Flatpak app still works. This
stuff is all incredibly tricky to get right at the different layers. It's
almost as if we need a better abstraction for these things.

We want to be closer to the host system environment than what we see
ourselves in the Flatpak runtime. This allows us to copy some variables
from the host as the user would see them natively.

This allows me to now run things like gtk4-demo inside a podman that is
used as a SDK runtime.

This private API attempts to extract the environment from the host so that
we can proxy necessary variables into new containers. In particular, this
is useful to get the correct XAUTHORITY, DISPLAY, and other things which
might be different in the Flatpak runtime.

Generally, you wouldn't do this, but since we are a developer tool that is
mostly just using Flatpak for packaging, it helps with the integration
tooling for podman, toolbox, etc.

We can't proxy this because it might not match the host $DISPLAY as
Flatpak could send us X99 instead of X0.

Fixes #1426