d/patches: prefer x-terminal-emulator

GNOME and glib currently do not provide any mechanism for setting a given terminal emulator as the default one. Since Debian has its own way of dealing with this specific problem, via the alternatives system, this patch makes glib use x-terminal-emulator instead of its hardcoded defaults, while keeping the pre-existing list as a fallback in case x-terminal-emulator is unavailable for some reason.

This solution has been recommended by upstream in the past, see https://gitlab.gnome.org/GNOME/glib/-/issues/338#note_205945

Cc: @biebl, @smcv

Closes: #773915

I'm reluctant to apply this without careful consideration of tradeoffs and alternatives, because it makes some scenarios better but makes other scenarios regress.

x-terminal-emulator is not actually a great interface for what we want here, because alternatives are system-wide, but the right default terminal is desktop-environment-specific. On a system with GNOME and KDE installed, x-terminal-emulator can only point to gnome-terminal or Konsole; but IMO the right default would be to run gnome-terminal (or kgx) in GNOME, run Konsole in KDE sessions, and maybe run x-terminal-emulator in non-freedesktop.org sessions (fvwm or whatever).

Ideally what we're looking for is something like https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/46, but unfortunately that proposed spec is entangled with https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45, which is very broad and generic (meaning nobody feels that they can approve it).

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2839 seems to have some traction upstream at the moment.

xdg-terminal-exec isn't currently packaged in Debian.

Does it follow a fd.o spec (either accepted or proposed), or its own ad-hoc thing?

I'm sympathetic towards wanting to have a much simpler spec that only tries to solve the Terminal problem and doesn't try to be as broad and general as https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45, but it doesn't seem great to have an "XDG" tool whose spec hasn't even been proposed as far as I can see.

🤷 I am not involved in it and don’t know the pros or cons at the moment, sorry

If we are going to apply a non-upstreamable patch for this, I would also prefer a patch that is written to minimize diffstat, even if that means the flow of execution is not quite what you would have done in a patch intended to go upstream.

I'm not going to apply this as part of packaging 2.74.1, but I'm also not rejecting it - more discussion and more thought needed.

Hi, thanks for your comments. I wasn't expecting this to be merged without discussions :)

x-terminal-emulator is not actually a great interface for what we want here, because alternatives are system-wide, but the right default terminal is desktop-environment-specific. On a system with GNOME and KDE installed, x-terminal-emulator can only point to gnome-terminal or Konsole; but IMO the right default would be to run gnome-terminal (or kgx) in GNOME, run Konsole in KDE sessions, and maybe run x-terminal-emulator in non-freedesktop.org sessions (fvwm or whatever).

I agree, but, at the same time, I think that this still does improve the situation in some scenarios. For example, it allows users to run Terminal=true apps with terminal emulators not listed in glib (I personally only have foot installed). It is also true that x-terminal-emulator can only point at one terminal at a time, but it at least allows the user to switch defaults without having to remove packages.

And yes, surely not everybody knows that they have to fiddle with update-alternatives to change their x-terminal-emulator, but it is surely more straightforward than having to look at glib's source; also, users caring enough about their default terminal emulator are somewhat likely to eventually discover update-alternatives and its uses.

In short: I believe that x-terminal-emulator is a more sensible choice than an hardcoded list.

it makes some scenarios better but makes other scenarios regress

What regressions do you have in mind?

Ideally what we're looking for is something like https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/46, but unfortunately that proposed spec is entangled with https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/45, which is very broad and generic (meaning nobody feels that they can approve it).

This patch doesn't aim at being a "perfect" solution, and I hope that a more suitable XDG spec gets developed that would make this obsolete.

If we are going to apply a non-upstreamable patch for this, I would also prefer a patch that is written to minimize diffstat, even if that means the flow of execution is not quite what you would have done in a patch intended to go upstream.

Would it be ok to skip indenting the code, or would you also prefer to alter the logic?

@smcv I just uploaded gnome-terminal 3.46.7 which added support for xdg-terminal-exec with a new preference for it (at the bottom of the screenshot):

Since your last comment here, glib 2.75.0 has shipped with this feature.

This will need some integration work to make sure the feature works appropriately for Debian 12. However, maybe it's worth the work?

Backporting the code layout from GLib 2.75 would be a reasonable way to get control over choice of terminal (and in particular xdg-terminal-exec support) without diverging from upstream. That would resolve my concerns about minimizing diffstat.

I still don't think x-terminal-emulator is a great interface for choosing a terminal, because its choice is based only on system-wide configuration and not on the desktop environment in use. xdg-terminal-exec nicely avoids that problem by using a MIME-like configuration precedence stack. After applying the upstream changes that make it possible to be a 1-line patch, I wouldn't object to a 1-line patch to add x-terminal-emulator to the list of things to try, but I think it should be low down the list (definitely lower than xdg-terminal-exec, and probably lower than GNOME's preferred terminals as well).

mentioned in merge request !22 (closed)

What regressions do you have in mind?

Sorry, I thought I'd already said this:

This whole topic is about how we launch TUI (interactive text UI) applications that have a .desktop file, like /usr/share/applications/mutt.desktop.

Suppose we have a shared computer used by Gertrude, a GNOME user, and Keith, a KDE user (other desktop environments are available, but those two are popular and make good examples). Also suppose for the sake of argument they both use mutt. Gertrude would ideally like to get TUI apps like mutt launched in kgx or gnome-terminal or similar, because those follow the behaviour and appearance conventions seen in GNOME. Similarly, Keith would ideally like to get TUI apps launched in Konsole or similar. If we used /etc/alternatives/x-terminal-emulator as top priority, it is not possible for both users to have what they want.

Gertrude will typically launch TUI apps like mutt via a GLib-based desktop environment (GNOME Shell overview, or gnome-panel, or similar) or as child processes of a GTK app (like clicking on a mailto: link in GNOME Web). Keith will typically launch TUI apps like mutt via a Qt-based desktop environment or a Qt/KDE app. We don't control how Keith's Qt/KDE apps choose their terminal emulator, because that's a decision for Qt/KDE libraries and outside our scope; but we do control how Gertrude's GTK apps choose their terminal emulator, so we can at least make sure the right thing happens by default for Gertrude (and that's what has happened since at least 2014).

gnome-terminal and Konsole have equal priority for the x-terminal-emulator alternative (both 40), so there's a 50% chance that on the system described here, Konsole is the x-terminal-emulator. That means if we preferred x-terminal-emulator (as proposed here) before Debian 12, there would be a 50% chance that Gertrude's mutt instances will change from gnome-terminal to Konsole after upgrade to Debian 12, which is a user-visible regression.

(Also, if GLib continues to prefer to use gnome-terminal, then Gertrude and Keith can agree to make x-terminal-emulator point to Konsole, and they will both get what they want, even if Qt/KDE libraries use x-terminal-emulator!)

The obvious objection to this is that Keith is probably using Chromium or Firefox, which are GTK apps, on his KDE desktop; but if that's the case, then Keith has unfortunately already had to accept a certain amount of GUI toolkit inconsistency, so using kgx or gnome-terminal seems non-ideal, but is at least continuing a pre-existing inconsistency?

Thank you very much for your exhaustive reply, it does make sense. Especially now that upstream Glib has moved towards a resolution to this issue I think that this patch has become obsolete.

And thanks for opening !22 (closed) too!

closed