We need a workaround because gtk_show_uri_on_window() is not working
correctly for us, despite the portal. We're opening the URI locally which
is not what we want.

# Conflicts:
#	src/libide/application/ide-application-actions.c

Simon McVittie authored Jul 11, 2018 and Christian Hergert committed Aug 13, 2018

This is an incompatible change, but so is async becoming an identifier.

Fixes: #565
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903558


Signed-off-by: Simon McVittie <smcv@debian.org>

If we get a second return value for the task, proxy the free request back
to the main context so that we don't hit assertions later on.

This allows us to work around the portal issue for now until upstream glib
gets a bug fix that we want.

# Conflicts:
#	src/libide/application/ide-application.c

We want to check for help docs, not sdk docs. Also, if enabled, don't be
automatic about it. Fail hard so the caller knows there is an issue.

This fixes a minor leak of FileInfo (last one per directory).

Florian Müllner authored Aug 05, 2018 and Christian Hergert committed Aug 06, 2018

Portals are explicitly designed to give sandboxed applications access to
resources in a secure manner, and flatpak therefore grants all applications
permission to talk to any portal.

As a result, few manifests will explicitly request that permission, so
to have apps work as expected when run through our flatpak-runner instead
of flatpak itself, we should grant them the same permission.

!95

By validating properties and changing state, we lost our FALSE state for
the dirty bit in the configuration. That resulted in write-back of the
configuration in situations where we don't want to do that.

This isn't necessary anymore since we use the builddir to store the
Makecache file.

This disables highlighting while we load the buffer to avoid some work
and potential races in gtksourceview.