On Sat, 28 Jan 2023 at 16:41:28 -0500, Jeremy Bicha wrote: > This solves a problem: currently you can use update-alternatives to > choose a default terminal for a Debian system, but what happens when > you have multiple users on the same Debian system with different > preferences?
Another problem that it solves is that when there has been no sysadmin configuration, the ideal default terminal is desktop-dependent, in order to coordinate with the desktop environment's design and conventions. If a GNOME user and a KDE/Plasma user share a desktop computer, and they both launch a terminal app like mutt, the expected result in the absence of any other configuration is that the GNOME user gets mutt displayed in a gnome-terminal or maybe gnome-console window, while the KDE user gets mutt displayed in a Konsole window. There is currently no possible target for the x-terminal-emulator symlink that will give both users the expected behaviour: one of them has to get the "wrong" terminal by default. (I know Jeremy knows this, but other -devel readers might not be aware.) If xdg-terminal-exec becomes the de facto standard in future, then we can probably make it a high-priority alternative for x-terminal-emulator (directly if it's command-line compatible, or via a script if it isn't). > I don't think the "proposed specification" has been fully drafted yet. > There is some discussion at > https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/54 > and over the years in the xdg mailing list. I haven't reviewed xdg-terminal-exec in detail, but at a high level it seems a lot more promising than making terminals a special case of a generic "intents" mechanism (which is a broad and vague topic which will likely take a correspondingly long time to standardize), or standardizing a D-Bus interface for terminals (which, as much as I like D-Bus as an implementation for things like o.fd.Application, is not something that the likes of xterm are ever likely to implement). However, the fact that the spec hasn't been standardized or even fully drafted makes me want to avoid adding xdg-terminal-exec to unstable/bookworm at this late stage of the release cycle: if it gets through NEW fast enough to be in bookworm and then the spec changes incompatibly, we'll be stuck with an implementation of the old version of the spec in Debian 12 for 3 years (+ LTS), which would be really annoying for cross-distro compatibility, both for us and for upstream. I think a better route might be to get it into experimental for now, then when it seems like it has stabilized more, put it into unstable/trixie and potentially also bookworm-backports. > More recently, the alpha for glib 2.76 (part of GNOME 44 Alpha) now > supports xdg-terminal-exec ... > We might backport the glib feature to Debian > Bookworm, but it is quite late in Bookworm's release process. I would be more positive about backporting this change before bookworm than I am about adding xdg-terminal-exec, because the GLib change is just that *if* xdg-terminal-exec is found in PATH, then GLib checks for it in preference to all the other terminals it knows about. If x-t-e is not found in PATH, then the GLib change has no benefit but also does no harm. (It also reshuffles the code around terminal selection in a way that allows more terminals to be added to the list as a 1-line change, which is a nice side benefit, and in particular would let us fall back to x-terminal-emulator without causing a huge diffstat and semi-frequent patch conflicts.) > and GNOME Terminal 3.46.7 includes the necessary metadata file ... > The metadata would also need to be added to other terminal emulator > apps This part is just the addition of X-ExecArg to the .desktop file, and a symlink to it in /usr/share/xdg-terminals/, yes? If that's the case then having this metadata in gnome-terminal and other terminal emulators seems uncontroversial - it's potentially helpful and unlikely to cause regressions or incompatibilities. A summary for those who have not looked into this: X-ExecArg tells xdg-terminal-exec how to invoke a terminal to run a specific command, like the "-e" of "xterm -e vi ~/myfile". It's -e for any terminal that can implement the Debian-specific x-terminal-emulator interface directly, but some terminal implementations need a different argument like "--" or no argument at all. The semantics of running a terminal with its X-ExecArg are similar to Debian Policy's x-terminal-emulator -e (option parsing stops after that argument, and arguments are placed directly into an argv without word splitting or a shell), which seems like the right design. The main reason why X-ExecArg needs to be per-terminal metadata is that some terminal emulators historically implemented "-e" as behaving more like "sh -c", which is not compatible with the desired semantics, but cannot be changed without a compat/API break (which terminal emulator authors are typically unwilling to do) or a wrapper script. Using "--" as the X-ExecArg is also a lot easier to implement with a GNU-style command-line parsing library. > and desktops that use glib would need to ship a metadata file > with their preferred terminal emulators It seems rather late to add these to bookworm, particularly if the spec might still change (I don't think the format of these metadata files is necessarily set in stone yet). However, if xdg-terminal-exec support becomes widespread during the trixie cycle, then adding the per-desktop-environment metadata files to at least the most major desktops would seem plausible to do in a point release - they aren't going to cause a regression for anything in bookworm, which doesn't look for those files. smcv