Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: i3-wm
Severity: normal
Tags: trixie sid
User: xdg-deskt...@packages.debian.org
Usertags: portals.conf

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

--
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

[Michael Stapelberg]

Hey Simon

Answers inline:

On Thu, 31 Aug 2023 at 13:27, Simon McVittie <sm...@debian.org> wrote:

Source: i3-wm
Severity: normal
Tags: trixie sid
User: xdg-deskt...@packages.debian.org
Usertags: portals.conf

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"?

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?

 

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.

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 

--

Best regards,
Michael

[Simon McVittie]

On Sun, 03 Sep 2023 at 20:25:52 +0200, Michael Stapelberg wrote:
> If I'm reading its code correctly, I think i3-wm asks the display manager
> to set XDG_CURRENT_DESKTOP to "i3"?
>
> 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-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.

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

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’m also not familiar with what these xdg portals are, and I don’t think I’m
> using them (yet)?

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.

> I don’t want to make the choice of whether gtk or qt should be used for parts
> of a user’s desktop.

...

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

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

[Michael Stapelberg]

Thanks for your explanations. Answers inline:

On Sun, 3 Sept 2023 at 22:55, Simon McVittie <sm...@debian.org> wrote:

On Sun, 03 Sep 2023 at 20:25:52 +0200, Michael Stapelberg wrote:
>     If I'm reading its code correctly, I think i3-wm asks the display manager
>     to set XDG_CURRENT_DESKTOP to "i3"?
>
> 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-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.

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

 

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

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.

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?

 

> I’m also not familiar with what these xdg portals are, and I don’t think I’m
> using them (yet)?

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.

> I don’t want to make the choice of whether gtk or qt should be used for parts
> of a user’s desktop.
...
> I think for the case of i3, the defaults should be fine, so I would prefer not
> to add this config file.

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).

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'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".

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. 

--

Best regards,
Michael

[Simon McVittie]

On Mon, 04 Sep 2023 at 18:56:52 +0200, Michael Stapelberg wrote:
> > i3 isn’t a desktop environment, it’s a window manager only.
>
> 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.
>
> 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?

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.

> 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).
>
> 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?

The -gtk backend was never really intended to be a fallback: it was
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.

> 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.

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

[Michael Stapelberg]

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.

 

>     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).
>
> 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?

The -gtk backend was never really intended to be a fallback: it was
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

Ah, thanks for raising the backward compatibility point upstream.

 

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.

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.

 

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.

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.

 

> 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.

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?

Pretty much :) 

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?

--

Best regards,
Michael

[Simon McVittie]

On Mon, 04 Sep 2023 at 21:03:30 +0200, Michael Stapelberg wrote:
> 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