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
