On Sat, 11 Jul 2020 at 12:31:44 +0200, Nis Martensen wrote:
> At this point I think we need help from someone more familiar with VTE.
> Simon, do you know this stuff or do you know someone who we could ask?
Sorry, I don't know VTE in detail. What I know about VTE is whatever I
find that I need to learn if there is a gnome-terminal regression, and
I usually forget it soon after. I'd suggest trying the GTK/GNOME team
(debian-gtk-gnome mailing list) if you need more VTE or GTK knowledge.
Someone (probably Paul Wise? I lost track of the attribution) wrote:
> > BTW, I think the GTK UI should not be running the MUAs under a VTE
> > terminal unless the MUA is marked as needing a terminal. Same for any
> > other commands it runs under a VTE terminal. For xdg-email probably
> > most of the commands that runs don't need a terminal.
I agree, and this might be a better long-term solution to the problem. If
the GTK UI is launching an email client via xdg-email, it should probably
just run the script, without doing anything special like wrapping it
in a VTE terminal. I'm using mutt.desktop, which has Terminal=true,
in a GNOME desktop, and xdg-email correctly opens a new instance of
my configured terminal (gnome-terminal) and runs mutt inside that; it's
essentially launching it like a GUI application, which happens to be
implemented by combining a terminal with a TUI. So running xdg-email in
a terminal would be redundant.
Unfortunately, xdg-email is a maze of desktop-specific code paths, all
different. I would hope that the various desktop- and toolkit-specific
code paths have approximately the same behaviour as GNOME, because they
should all be using somewhat generic "launch this app" infrastructure,
which should do the right thing... but I can't guarantee that. The
open_generic code path, used on LXQT and Enlightenment, definitely
*doesn't* do the right thing for Terminal=true MUAs (I've opened #964877).
It might be safer to build a corresponding mailto:
URI (which is desktop-agnostic and can be done in
pure Python), and then pass it to whatever is the Python
binding for g_app_info_launch_default_for_uri_async() (probably
Gio.AppInfo.launch_default_for_uri_async() or similar). That ends up doing
the same thing as the GNOME 3, Cinnamon, etc. code path in xdg-email(1),
but with 100% less shell script, using only library code that is a hard
dependency for GTK anyway. This definitely *does* handle Terminal=true
MUAs correctly. The down side of this approach is that you get #773915,
because there is no generic mechanism to choose a per-user or per-desktop
preferred terminal emulator: in Debian we do have the x-terminal-emulator
alternative, but that's Debian-specific (which makes upstreams wary), and
isn't per-user or per-desktop (so if Alice prefers GNOME, and shares a
computer with Bob who prefers KDE, there is no setting for the
x-terminal-emulator alternative that will respect both their preferences).
smcv
