Re: Desktop Entry Specification: Add new ExecArg key

--Apple-Mail=_F7A56A2E-9DFC-4287-A763-66BB01FC87A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> ExecArgs only guarantees a working interface.=20

Btw thats what the proposal says. Imho that's a design flaw in the =
proposal.

ExecArg should also imply that it is a terminal, making the =
Categories=3DTerminalEmulator redundant. That's the only thing we are =
interested in since the `xdg-terminal-execute [opts] <commandline>` =
manages *terminals that have a command execution interface*.

However we cannot enforce terminals to have that interface and the =
proposal as is allows invalid configurations.=20

Take for example yakuake. It is impossible to configure it correctly. It =
is a terminal because it uses the desktop menu =
Categories=3DTerminalEmulator, it does not allow command execution and =
it does not define ExecArg. As such the proposal will default and =
execute it with -e.

Another fundamental broken thing is backward compatibility. All terminal =
emulators not having the `-e` interface and not defining Exec Arg have =
an invalid configuration.=20

--

While trying to push this proposal by pinging terminal authors to add =
this key to their desktop entries @chpe (GNOME terminal maintainer, the =
only terminal having X-ExecArg upstream) told me that he'd prefer the =
terminal app intent (TAI) approach instead.

I agree that the intents concept is more general and sophisticated =
approach. We should not argue with (dis-)advantages of general concepts =
about its particular use cases though. It's not about Intents vs =
xdg-terminal-execute (XTE), but rather TAI vs XTE (if at all). A =
decision for XTE is not a decision against intents (not even necessarily =
against TAI imho).

Some facts/notes on the "competing" approaches (correct me if wrong):

What do we need?=20
TAI requires intents to be a thing, terminals have to implement the TAI =
DBus interface and to be DBus activatable and therefore to be single =
instance app. That's a _huge_ requirement since it may even require to =
redesign the architecture of a terminal app.
XTE requires a command execution interface and a failsafe way to use it.

Where we are:=20
TAI: Intents is draft. TAI is a draft. None of the terminals has a TAI =
implementation. Basically nothing practical happened yet.
XTE: XTE is a draft. Reference implementations exists. Command execution =
interfaces in almost all terminals _do_ exist.

What is to be done?=20
TAI: Nothing has been done yet. So everything that we need.
XTE: ExecArgs in desktop entries of terminals. And the draft to be im- =
and approved.

Potential future problems?
TAI: The proposals are huge. It will take time and requires volunteers =
and a lot of community efforts. Xterm and the like are probably not =
going to implement it ever and even modern terminals refuse to implement =
it (link =
<https://github.com/alacritty/alacritty/issues/8089#issuecomment-223423696=
0>). Basically it is questionable if this is ever going to work out such =
that it matches users expectations (having full terminal coverage).
XTE: None afaik. The ExecArg approach is _one-line_ in the desktop entry =
which tends to be more welcome upstream requirement (link =
<https://github.com/alacritty/alacritty/issues/8089#issuecomment-223183636=
4>). Actually its does not even have to touch upstream source because a =
one-liner can be patched by packagers and even allows backporting this =
feature.

My personal (pragmatic) opinion:

TAI and app intents in general are nice ideas. However for this use case =
it seems like overkill to my eyes. Also it is not a real solution since =
it is not realistically able to get the same coverage as XTE will, not =
even if the cost (which is simply high) is not taken into account. As =
the author of a launcher and in the name of my users I dare to say that =
we should go with coverage. XTE provides it. Even better it can be =
achieved in near future. I am not arguing against TAI. I just vote for =
going ahead with simple solutions that we _can_ provide to our users =
_now_. In future it must not even conflict TAI. Implementations could =
still take both specs into account and we can still settle on TAI in =
future if a good fraction of terms support it. However the plain =
existence of a future idea cant inhibit a practical yet complete =
solution to get off the ground, can it?

What do you think?






--Apple-Mail=_F7A56A2E-9DFC-4287-A763-66BB01FC87A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;"><span><blockquote type=3D"cite">ExecArgs only =
guarantees a working interface.&nbsp;</blockquote><br></span><span>Btw =
thats what the proposal says. Imho that's a design flaw in the =
proposal.</span><div><span><br></span><span>ExecArg should also imply =
that it is a terminal, making&nbsp;</span>the =
Categories=3DTerminalEmulator redundant. That's the only thing we are =
interested in since the `xdg-terminal-execute [opts] =
&lt;commandline&gt;` manages&nbsp;*terminals that have a command =
execution interface*.</div><div><span><br></span><span>However we cannot =
enforce terminals to have that interface and the proposal as is allows =
invalid =
configurations.&nbsp;</span></div><div><span><br></span></div><div><span>T=
ake for example yakuake. It is impossible to configure it correctly. =
I</span>t is a terminal because it uses the desktop =
menu&nbsp;Categories=3DTerminalEmulator, it does not allow command =
execution and it does not define ExecArg. As such the proposal will =
default and execute it with -e.</div><div><span><br></span><span>Another =
fundamental broken thing is backward compatibility. All terminal =
emulators not having the `-e` interface and not defining Exec Arg have =
an invalid =
configuration.&nbsp;</span></div><div><div><div><br></div><div>--</div><di=
v><br></div><div>While trying to push this proposal by pinging terminal =
authors to add this key to their desktop entries @chpe (GNOME terminal =
maintainer, the only terminal having X-ExecArg upstream) told me that =
he'd prefer the terminal app intent (TAI) approach =
instead.</div><div><br></div><div>I agree that the intents concept is =
more general and sophisticated approach. We should not argue with =
(dis-)advantages of general concepts about its particular use cases =
though. It's not about Intents vs xdg-terminal-execute (XTE), but rather =
TAI vs XTE (if at all). A decision for XTE is not a decision against =
intents (not even necessarily against TAI =
imho).</div><div><br></div><div><div>Some facts/notes on the "competing" =
approaches (correct me if wrong):</div><div><br></div></div><div>What do =
we need?&nbsp;</div><div>TAI requires intents to be a thing, terminals =
have to implement the TAI DBus interface and to be DBus&nbsp;activatable =
and therefore to be single instance app. That's a _huge_ requirement =
since it may even require to redesign the architecture of a terminal =
app.</div><div>XTE requires a command execution interface and a failsafe =
way to use it.</div><div><br></div><div>Where we =
are:&nbsp;</div><div>TAI: Intents is draft. TAI is a draft. None of the =
terminals has a TAI implementation. Basically nothing practical happened =
yet.</div><div>XTE: XTE is a draft. Reference implementations exists. =
Command execution interfaces in almost all terminals _do_ =
exist.</div><div><br></div><div>What is to be done?&nbsp;</div><div>TAI: =
Nothing has been done yet. So everything that we need.</div><div>XTE: =
ExecArgs in desktop entries of terminals. And the draft to be im- and =
approved.</div><div><br></div><div>Potential future =
problems?</div><div>TAI: The proposals are huge. It will take time and =
requires volunteers and a lot of community efforts. Xterm and the like =
are probably not going to implement it ever and even modern terminals =
refuse to implement it (<a =
href=3D"https://github.com/alacritty/alacritty/issues/8089#issuecomment-22=
34236960">link</a>). Basically it is questionable if this is ever going =
to work out such that it matches users expectations (having full =
terminal coverage).</div><div>XTE: None afaik. The ExecArg approach is =
_one-line_ in the desktop entry which tends to be more welcome upstream =
requirement (<a =
href=3D"https://github.com/alacritty/alacritty/issues/8089#issuecomment-22=
31836364">link</a>). Actually its does not even have to touch upstream =
source because a one-liner can be patched by packagers and even allows =
backporting this feature.</div><div><br></div><div>My personal =
(pragmatic) opinion:</div><div><br></div><div>TAI and app intents in =
general are nice ideas. However for this use case it seems like overkill =
to my eyes. Also it is not a real solution since it is not realistically =
able to get the same coverage as XTE will, not even if the cost (which =
is simply high) is not taken into account. As the author of a launcher =
and in the name of my users I dare to say that we should go with =
coverage. XTE provides it. Even better it can be achieved in near =
future. I am not arguing against TAI. I just vote for going ahead with =
simple solutions that we _can_ provide to our users _now_. In future it =
must not even conflict TAI. Implementations could still take both specs =
into account and we can still settle on TAI in future if a good fraction =
of terms support it. However the plain existence of a future idea cant =
inhibit a practical yet complete solution to get off the ground, can =
it?</div><div><br></div><div>What do you =
think?</div><div><br></div><div><br></div><div><br></div><div><br></div><d=
iv><br></div></div><div></div></div></body></html>=

--Apple-Mail=_F7A56A2E-9DFC-4287-A763-66BB01FC87A6--