Desktop Entry Specification: Add new ExecArg key

[Manuel Schneider]

> ExecArgs only guarantees a working interface. 

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=TerminalEmulator 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. 

Take for example yakuake. It is impossible to configure it correctly. It is a terminal because it uses the desktop menu Categories=TerminalEmulator, 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. 

--

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? 
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: 
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? 
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-2234236960>). 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-2231836364>). 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?





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20240724/0eabe129/attachment.htm>