Re: Desktop Entry Specification: Add new ExecArg key

Thayne <[email protected]> Wed, 17 Jul 2024 00:46:24 -0600
Newsgroups gmane.linux.xdg.devel
Message-ID <CALbpH+gQufFOMUDt5Ta1QG8HM0oaOuie8L0XeA4x7T721wpj=g@mail.gmail.com>
--000000000000ccef32061d6bd2df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

FWIW, adding an ExecArgs parameter to the desktop entry doesn't solve the
problem of determining which terminal to use. How does albert deal with
that?



On Tue, Jul 16, 2024 at 9:15=E2=80=AFAM Manuel Schneider <manuelschneid3r@g=
mail.com>
wrote:

> I commented
> <https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_reques=
ts/3#note_2490069> on
> the PR. I copy it for the mailing list here:
>
> To get an impression of the current state check the hard coded list of
> exec args of popular terms
> <https://github.com/albertlauncher/albert/blob/6783257df7e15dcfbae49d0302=
3414b7c3692dbd/src/app/terminalprovider.cpp#L120-L150> I
> (try to) maintain for albert launcher. -e is indeed common for a majority
> of terminals.
>
> I guess that this -e majority just emerged out of the absence of a real
> standard with the common focal point of the ancient xterm interface.
> Nothing that was ever really thought out.
>
> I think we should not default to -e despite being quasi standard. I think
> that we should not default at all. Some terminals don't support command
> execution. We have to handle this.
>
> Imho the absence of the ExecArgs should indicate that the terminal does
> not support command execution. This is compatible with existing desktop
> entries. ExecArgs should be allowed to exist but be empty, which will fit
> the foot and kgx interface.
>
> Generally defaulting to anything would define an arbitrary standard
> terminal command execution interface. Nothing sophisticated. Nothing
> terminal developers should be imposed on.
>
> Imho the self-reporting of the command execution interface in the desktop
> entry is a feature on its own. A standard (your proposal) could then buil=
d
> on top of it. Later fancy extensions on how to collate windows under X or
> Wayland can be discussed. They are rather opinionated and hinder the
> realization of the former, rather simple and objectively useful ideas.
>
> Also I wonder if this PR makes sense at all in the terminal-wg. These
> proposals are not related to terminal standards. It is rather a general
> desktop environment thing. Especially since I skimmed through #24
> <https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/24> a=
nd
> none of the admins left a comment in the past 5 years. Shouldn't it go to
> https://gitlab.freedesktop.org/xdg/xdg-specs?
>

--000000000000ccef32061d6bd2df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">FWIW, adding an ExecArgs parameter to the desktop entry do=
esn&#39;t solve the problem of determining which terminal to use. How does =
albert deal with that? <br clear=3D"all"><div><div><div dir=3D"ltr" class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><br></div></div><br=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Jul 16, 2024 at 9:15=E2=80=AFAM Manuel Schneider &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I=C2=A0=
<a href=3D"https://gitlab.freedesktop.org/terminal-wg/specifications/-/merg=
e_requests/3#note_2490069" target=3D"_blank">commented</a>=C2=A0on the PR. =
I copy it for the mailing list here:=C2=A0<div><br></div><blockquote style=
=3D"margin:0px 0px 0px 40px;border:medium;padding:0px"><div>To get an impre=
ssion of the current state check the hard coded<a href=3D"https://github.co=
m/albertlauncher/albert/blob/6783257df7e15dcfbae49d03023414b7c3692dbd/src/a=
pp/terminalprovider.cpp#L120-L150" target=3D"_blank"> list of exec args of =
popular terms</a>=C2=A0I (try to) maintain for albert launcher. -e is indee=
d common for a majority of terminals.</div><div><br></div><div><div>I guess=
 that this -e majority just emerged out of the absence of a real standard w=
ith the common focal point of the ancient xterm interface. Nothing that was=
 ever really thought out.</div></div><div><div><br></div></div><div><div>I =
think we should not default to -e despite being quasi standard. I think tha=
t we should not default at all. Some terminals don&#39;t support command ex=
ecution. We have to handle this.</div></div><div><div><br></div></div><div>=
<div>Imho the absence of the ExecArgs should indicate that the terminal doe=
s not support command execution. This is compatible with existing desktop e=
ntries. ExecArgs should be allowed to exist but be empty, which will fit th=
e foot and kgx interface.</div></div><div><br></div><div><div>Generally def=
aulting to anything would define an arbitrary standard terminal command exe=
cution interface. Nothing sophisticated. Nothing terminal developers should=
 be imposed on.</div></div><div><br></div></blockquote><div>Imho the self-r=
eporting of the command execution interface in the desktop entry is a featu=
re on its own. A standard (your proposal) could then build on top of it. La=
ter fancy extensions on how to collate windows under X or Wayland can be di=
scussed. They are rather opinionated and hinder the realization of the form=
er, rather simple and objectively useful ideas.</div><div><br></div><div>Al=
so I wonder if this PR makes sense at all in the terminal-wg. These proposa=
ls are not related to terminal standards. It is rather a general desktop en=
vironment thing. Especially since I skimmed through=C2=A0<a href=3D"https:/=
/gitlab.freedesktop.org/terminal-wg/specifications/-/issues/24" target=3D"_=
blank">#24</a>=C2=A0and none of the admins left a comment in the past 5 yea=
rs.=C2=A0Shouldn&#39;t it go to=C2=A0<a href=3D"https://gitlab.freedesktop.=
org/xdg/xdg-specs" target=3D"_blank">https://gitlab.freedesktop.org/xdg/xdg=
-specs</a>?</div></div></blockquote></div>

--000000000000ccef32061d6bd2df--