On Sun, 14 Jun 2026 at 10:30:45 +0200, Matthias Geiger wrote:
+# Wayland
+ - name: wayland-terminal-emulator
+ description: a wayland client which emulates a terminal with a
terminfo description
What's the intended purpose of this virtual package? Which packages are
expected to interact with it?
If providing the virtual package requires implementing a specific
alternative (via dpkg's update-alternatives), then I think the entry in
Policy's list should say so. But I'm already not a fan of the use of
alternatives for x-terminal-emulator, because I think it's a bad fit for
what desktop environment users expect.
The alternatives mechanism is great for choices that are necessarily
one-per-machine and must be chosen system-wide, like the display manager
(graphical login prompt) or other system services, and it can make a
good fallback for the last-resort implementation of some app, but it has
some quite serious limitations as a primary way to select user-facing
apps. If George and Kay install a shared computer with both GNOME and
KDE, George uses GNOME and Kay uses KDE, and neither user has configured
a personal preference, then it's a reasonable expectation that George's
default terminal emulator should be the one that GNOME recommends
(currently ptyxis) and Kay's should be the one that KDE recommends
(currently konsole). Neither terminal is better than the other in the
abstract, but ptyxis is a better fit for GNOME, and Konsole is a better
fit for KDE. But if their applications start x-terminal-emulator, then
there's no way to represent that expectation, and at most one of our two
users can get what they want.
Worse, only the sysadmin can configure what an alternative means (and,
again, when they do, it is system-global); the best the users can do
without privileges is to create a directory like ~/.local/bin, add it to
their PATHs (not done by default!), and create a symlink
~/.local/bin/x-terminal-emulator -> /usr/bin/ptyxis or similar, which is
not particularly discoverable, and not something that a settings UI can
reasonably be expected to do for them, especially if that settings UI is
not designed to be Debian-specific.
I think a better model for applications that want to start "some
suitable terminal emulator" is xdg-terminal-exec, which implements a
proposed freedesktop.org spec modelled on fdo MIME-type and URI-scheme
handlers, with a system-wide fallback, a per-desktop-environment
preference and a per-user configuration override. Or, this
terminal-specific proposal might be replaced at some point by an
interface name for the more general "intent apps" spec proposal,
<https://specifications.freedesktop.org/intent-apps/latest/>, which is
syntactically different but the same general shape.
A limitation of these .desktop-based specifications is that they don't
currently accommodate terminal emulators that *only* implement Wayland:
they assume that GUI apps are GUI apps, and will work in any reasonable
environment, perhaps via switchable backends (like in GTK, Qt, SDL) or
perhaps by using X11 via Xwayland as a lowest-common-denominator GUI
protocol (like xterm). The same is true for fdo MIME-type handlers, fdo
URI-scheme handlers, and the .desktop specification in general. If you
consider Wayland-only, non-X11-compatible apps to be an important
use-case, then the way to accommodate them would be to extend
https://specifications.freedesktop.org/desktop-entry/latest/recognized-keys.html
with new keys similar to OnlyShowIn/NotShowIn, but based on
$XDG_SESSION_TYPE (x11/wayland) instead of $XDG_CURRENT_DESKTOP
(GNOME/KDE/etc.).
Does your proposed design mean that anything that starts a terminal via
a wayland-terminal-emulator alternative (which could include non-GUI
libraries like GLib!) is expected to be able to detect whether the
session is Wayland or not, and use wayland-terminal-emulator
alternatives as a candidate for starting a terminal if and only if the
session is Wayland? At the moment GLib only has a list of terminals (to
which we apply a Debian-specific patch to include x-terminal-emulator),
and assumes that they will all work in any "reasonable" desktop
environment, similar to how .desktop files work - which in practice is
true because all the terminals on its list either use GTK/Qt to support
any desktop environment, or are X11-only (like xterm) and will operate
via Xwayland on Wayland desktops.
And how does this work for terminals that don't/can't know whether they
implement native Wayland? GTK 3+ applications can typically be both a
Wayland client and an X11 client, using whichever protocol is more
appropriate at runtime, and I know there are also Wayland-only terminal
emulators like foot and X11-only terminal emulators like xterm. But if I
understand the Qt ecosystem correctly, a Qt-based application like
Konsole might or might not be able to implement native Wayland,
depending on whether the plugins in the qt6-wayland package are
installed, with no code changes to the application itself - so is
konsole a wayland-terminal-emulator or not?
smcv
