On Mon, 4 Sept 2023 at 19:54, Simon McVittie <s...@debian.org> wrote:
> 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. > 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
