Thanks for your explanations. Answers inline: On Sun, 3 Sept 2023 at 22:55, Simon McVittie <s...@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
