Fix portal avoidance

[matthiasclasen]

The code currently has g_unsetenv ("GTK_USE_PORTAL") as an attempt to prevent users from opting in to using portals in a portal implementation.

It has been ineffective for a while, since GTK is no longer reading that environment variable.

And in 4.18, we will make portal use opt-out instead of opt-in.

At the same time, we've added gdk_display_set_no_portals().

So once we depend on GTK 4.17, we should replace that unsetenv call with gdk_display_set_no_portals (gdk_display_get_default ())

[smcv]

x-d-p-gtk is still GTK 3. How does this work in GTK 3 world? Is unsetting GTK_USE_PORTAL still the way to do it there?

once we depend on GTK 4.17, we should replace that unsetenv call with gdk_display_set_no_portals (gdk_display_get_default ())

For GTK-4-based portals (x-d-p-gnome), adding that call immediately, in a suitable #if GTK_CHECK_VERSION... block, seems like it would be a good idea.

Distros will normally upgrade from 4.16 to 4.17 to 4.18, or directly from 4.16 to 4.18, without immediately recompiling dependent projects like x-d-p-*. Is there a way portal implementations can prevent infinite recursion without a hard dependency on a development version of GTK? Perhaps g_module_open(NULL, .), g_module_symbol(., "gdk_display_set_no_portals", .), and call it if successful?

once we depend on GTK 4.17, we should replace that unsetenv call

After the minimum GTK to compile a portal implementation gets high enough, yes it can drop the g_unsetenv.