Bug#1029907: ITP: xdg-terminal-exec -- user default terminal execution utility
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
Reply to: