xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/i3-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

If I'm reading its code correctly, I think i3-wm asks the display manager
to set XDG_CURRENT_DESKTOP to "i3"?

As a backwards-compatibility mechanism, x-d-p will fall back to trying to
guess the most appropriate portals from the portals' deprecated UseIn=
fields, but it will log warnings when it does that, and anyway Debian
doesn't currently ship any portal backends that are flagged as suitable
for i3. Please add an i3-portals.conf to tell x-d-p more explicitly
what backends i3-wm is meant to be using by default.

For example, if the intention is to use the x-d-p-gtk backend,
the way to write that would be:

[preferred]
default=gtk;

The desktop environment (either i3-wm or some larger metapackage) should
probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
    smcv

Hey Simon

Answers inline:

I don’t know what code you’re referring to.
I don’t recall i3 asking any display manager anything, but maybe I’m
missing something?


i3 isn’t a desktop environment, it’s a window manager only.

I don’t want to make the choice of whether gtk or qt should be used for
parts of a user’s desktop.
I’m also not familiar with what these xdg portals are, and I don’t think
I’m using them (yet)?

I think for the case of i3, the defaults should be fine, so I would prefer
not to add this config file.

If you think i3 should provide a portal file, it would probably be best to
discuss upstream:
https://github.com/i3/i3/issues

i3-wm_4.22-2/share/xsessions/i3.desktop contains DesktopNames=i3, which is
how you ask a display manager to set XDG_CURRENT_DESKTOP=i3 when running
the command defined in i3.desktop as an X11 session.

It's behaving like a (very small) desktop environment to the extent that
it installs a file in /usr/share/xsessions, which results in it appearing
in the menu of possible session types in display managers like gdm,
lightdm or sddm.

I don't expect that i3 uses them, but some of the applications that users
run within an i3 session are going to be using them.

The most prominent use is that sandboxed Flatpak and Snap apps make D-Bus
calls to xdg-desktop-portal to get things like File -> Open and File ->
Save As dialogs, ask to open URLs or files outside the sandbox, pop up
notifications, take screenshots and other outside-sandbox actions.
xdg-desktop-portal implements all those things by passing on the request
to a backend such as xdg-desktop-portal-gtk, which can be desktop-specific.

Non-sandboxed apps are starting to use the same portal mechanism to do
things that are otherwise hard to do in a desktop-independent way, like
screenshots, screen-sharing and remote-desktop.
...

When we stop patching xdg-desktop-portal to hard-code its GTK backend
as a fallback, the default will be to use no portal backends at all,
which means the apps I described above will try and fail to make use of
those desktop features, unless the user has written a portals.conf(5)
of their own (which they can always do anyway, and it will overrule the
desktop environment's choices).

I'm aware that i3 is quite an "assemble it yourself" environment, so
perhaps users of i3 would expect to have to write their own configuration
to make things like this work? If that's the case then this could be
closed as "won't fix".

    smcv

Thanks for your explanations. Answers inline:

Ah, understood. Apparently, this line was needed for gdm, at least per the
2016 changelog entry.

Are you saying only desktop environments may install to the xsessions
directory?

If so, what is the mechanism for window managers to show up in the display
manager menu?

Uhm, why would we actively remove the fallback?
I don’t understand the logic behind that.
It seems like a decision that will leave users worse off, for no benefit?


I would interpret the lack of a config file as “just make a reasonable
choice for me”,
so I would say users expect portals to work, in some unspecified way.

I would certainly be surprised if portals just didn’t work,
when they could just fall back to the gtk implementation.

It depends where you draw the line between window manager and desktop
environment. Where I would personally draw that line is:

If it makes sense to log in to a thing as a desktop session in its own
right, which has some way to run programs in order to be independently
useful, and preferably some way to exit, then it makes sense to register
it in xsessions, and it's effectively behaving like a tiny desktop
environment. For instance, openbox and icewm are definitely this: each
has a menu that can launch apps and exit. You could call this a desktop
environment, or if you think that term has other connotations which
don't apply here, you could call it something else, but it's certainly
something that is useful to list as an option in e.g. lightdm.

If it doesn't make sense to log in to a thing because it isn't useful on
its own, then I don't think it should be registered in xsessions or show
up in the display manager menu. For instance, the /usr/bin/mutter in the
mutter package is a window manager, but it intentionally isn't registered
as an xsession, because it isn't useful on its own: it will manage the
windows of any programs you run some other way, but it doesn't have any
built-in way to start any programs, so you need to add at least a way to
run programs (some sort of menu or panel or hotkey mechanism, which it
doesn't have built-in) to make a directly useful user-facing environment.

I don't know which of those i3 wants to be.
originally GNOME-specific, and only got used in other environments
as a last resort because of implementation details of how the portal
backend is selected. The upstream design of x-d-p was always intended
to be that each GUI environment would provide its own choice of backend
(either its own, or shared with other GUI environments) that implements
the various interfaces in a desktop-appropriate way.

I suggested in an upstream issue[1] that maybe x-d-p-gtk should be
hard-coded as the portal backend of last resort (as I've done downstream
in Debian for now), but upstream developers didn't think that was
appropriate, and the user who originally opened the issue thought that
an unconfigured x-d-p specifically *shouldn't* start any backends,
so your opinion on this is noted but is not universally shared.

[1] https://github.com/flatpak/xdg-desktop-portal/issues/1077

We have had some quite bad bugs in the past caused by portal backends
being run outside their intended environment, failing to find the
desktop-specific services that they need (for example for screen sharing
and screencasting under Wayland, which are very implementation-specific),
and causing crashes or arbitrary delays, so it's important to avoid
x-d-p's old behaviour where it would arbitrarily pick *any* backend
if there is none that declares that it supports the current desktop
environment. I don't *think* x-d-p-gtk has any such interfaces, but I'm
not in a position to routinely test it on every GUI environment offered
by Debian.

One option that I've thought about is providing a
xdg-desktop-portal-fallback-is-gtk package, containing a
non-desktop-specific /usr/share/xdg-desktop-portal/portals.conf and
depending on x-d-p-gtk, and making that the default alternative for the
x-d-p-backend virtual package, so that Flatpak, Snap, Chromium, etc.
will pull it in as a dependency if no installed desktop environment
already depended on something more appropriate.

The major down side of that is that it would suppress the fallback
code path that uses the deprecated UseIn mechanism, resulting in the
wrong backend being chosen in environments that *do* have a preferred
backend (KDE Plasma, wlroots-based environments, Cinnamon/MATE/XFCE)
if they have not already added their own ${desktop}-portals.conf, so
we can't do that yet; but maybe after #1050798, #1050801, #1050802,
#1050803, #1050913, #1050914, #1050917 have been fixed?

A constraint here is that the more time I spend on maintaining fallbacks
and last-resorts for GUI environments that I don't, myself, use, the
less time I have available for making things better in fully-integrated
environments like the one that is the closest we have to a default; and
the same is true for the upstream maintainers of x-d-p and x-d-p-gtk.

So users of i3 will expect xdg-desktop-portal to "do what I mean", make
use of backends that are suitable for i3, and not make use of backends
that are not suitable for i3, without the benefit of any information
about what might or might not be suitable for i3?

That doesn't seem amazingly maintainable, but if the feedback I'm getting
is that I'm responsible for reading users' minds, I suppose I'll have
to put that on my list of things to feel guilty about having not done.

    smcv

i3 definitely aims to be useful on its own, but it also specifically does
not supply enough parts to constitute a full desktop environment.

For features that are unequivocally needed, even among niche window
managers,
i3 will have a component or recommendation (i3bar, i3status, i3lock, dmenu),
but you’re free to swap these out, or decide not to use them.


Ah, thanks for raising the backward compatibility point upstream.

Right. I don’t expect you (or anyone) to routinely test all environments.
But dropping x-d-p-gtk as fallback, which presumably works better than “no
portals”,
just doesn’t seem like a good step — upstream opinion notwithstanding.

Right. Maybe the answer here is that the burden should be shared
between the various niche window managers that want a generic solution.

But I don’t think asking every one of those window managers
to come up with their own solution is a good strategy either.
For a user without visibility into the various development processes,
the first thought will be “It used to work, so why can’t it keep working?”

Sorry for being difficult and complaining. I realize you seem to be just
the messenger.

To end this mail on a more productive note, hopefully:
What do other Linux distributions do? Do they have a similar downstream
patch?
If not, maybe it doesn’t matter much and users aren’t relying on the portal
functionality after all?

Variously:

* more opinionated distributions like Fedora, Ubuntu and Steam Deck make
  sure this sort of thing works for their flagship desktop environments,
  and anything beyond that is outside their scope;

* more DIY distributions like Arch and Gentoo will presumably expect each
  user of a non-major GUI environment to configure this for themselves,
  with an elaborate wiki page containing advice that might even be accurate;

* anything LTS doesn't have the version of xdg-desktop-portal with this
  change yet, and will have to deal with it when they get there

    smcv

Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.

A few months after you wrote the the comment above, you successfully
submitted a version of Debian's GTK-portal-as-last-resort mechanism to
Flatpak as a more permanent feature.
https://github.com/flatpak/xdg-desktop-portal/pull/1199

In light of this, should this and similar bugs be closed?

Lightweight window managers that do not depend on or recommend any
specific UI toolkit or D-Bus services have no way of knowing what their
users will prefer to use as they are not providing it themselves, so
the approach you took in Flatpak seems preferable to the one
recommended here.

Regards,
Timothy Gaskell