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
