ExecArg

[ManuelSchneid3r]

From the mailing list :

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 fundamentally broken thing is backward compatibility. All terminal emulators not having the -e interface and not defining Exec Arg have an invalid configuration.

[Vladimir-csp]

Still thinking.

Current state works for lots of cases without changes upstream. Unsupported terminals situation can be mitigated by a blacklist (made as a config extension probably).

Enforcing ExecArg as terminal eligibility marker will make most stuff not work until upstream or distro changes are made.

Current state may be treated as temporary, spec proposition updated with a transition statement, then we wait for uncertain future. Still thinking.

[ManuelSchneid3r]

Current state works for lots of cases without changes upstream. Unsupported terminals situation can be mitigated by a blacklist (made as a config extension probably).

Sure, a default of -x would also work for lots of cases. The problem is the incompatibility. Some terminals dont have such an interface and the spec has to be able to take this into account. Also defining a default would specify a quasi standard which I think is not a good idea since it is basically random.

Enforcing ExecArg as terminal eligibility marker will make most stuff not work until upstream or distro changes are made.

Having to wait for upstream (or packaging) changes is less of a problem than having cases that we cant handle ever (no command execution interface) or that are failing (upstream does not set ExecArg but the actual argument is any other than -e. If we do it, we should do it right. No matter how long it will take upstreams to adopt.

Current state may be treated as temporary, spec proposition updated with a transition statement, then we wait for uncertain future. Still thinking.

Undoing the current state would be a breaking change and we would have to increment the current major version of the desktop entry spec to v2.0. This is too invasive and tbh I guess it will never happen, since folks are keen on backward compatibilty.

[ManuelSchneid3r]

This is way to complicated for such a simple standard.

Fallback exclusions will not work in general or otherwise would have to be maintained for every distro release! The terminals break their command line interface over versions. Iirc I had at least three of such cases in the time I maintain this hardcoded list for albertlauncher. The spec has to work without such lists.

Considering the defacto standard -e. This is a plain heritage of the xterm interface. Nothing reasonable. What if it changes? The trend is obvious: Modern terminals tend to use the remainder of the commandline composed of unrecognized positional arguments optionally separated by -- (ptyxis, blackbox, kitty, contour, org.gnome.terminal). This seam natural to me. The fact that -e is used by the majority is not an argument to define a standard. What if in like two decades most of them use -x or --? If we dont have to we should not define a standard. KISS, especially not if it is going to break some setups.

Honestly what is the problem with beeing explicit in the ExecArg? There are like two or three dozens of terminals around. Its not that much of an effort to contact the maintainers to get stuff done right. Its such a minichange that we could even send PRs without much hassle (most of them are on github and gitlab). Just to illustrate how absurd it would be to bend a spec for a subset of terms, this is the list of (popular) -e terms:

• alacritty
• tilix
• gnome console
• deepin
• lxterminal
• konsole
• qterminal
• simpleterm
• terminology
• termite
• wezterm
• xterm
• urxvt
• xfce term

Note: The only gain we have is that these terminals work out of the box.

This gain will vanish over time (as some of them dont use -e anymore or the explicit ExecArg found its way into upstream sources). The problems I mentioned here and on the mailing list as well as the required maintenance work will stay there forever.

Seriously, please reduce the complexity of the spec.

[alttabber]

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.

I don't think this is a particularly good idea: what if 20 years from now, for whatever reason, someone somewhere needs to use ExecArg for something other than a terminal? Needing the TerminalEmulator category might seem redundant, but allows ExecArg to be used later on in other specs.

Current state works for lots of cases without changes upstream. Unsupported terminals situation can be mitigated by a blacklist (made as a config extension probably).

Enforcing ExecArg as terminal eligibility marker will make most stuff not work until upstream or distro changes are made.

Why should we be concerned with the current state of upstream? We're making a brand new spec, of course upstream does not support it yet. Upstream has to comply with the spec, not the other way around.

Also, this is a trivial spec to implement, we can expect most upstreams to ship it the very next release after this spec is finalized, how long will it take? A few months? Compared to the several years this spec has been in the making, that's the blink of an eye.

Current state may be treated as temporary, spec proposition updated with a transition statement, then we wait for uncertain future. Still thinking.

Nothing is more permanent than a temporary solution.

[ManuelSchneid3r]

I don't think this is a particularly good idea: what if 20 years from now, for whatever reason, someone somewhere needs to use ExecArg for something other than a terminal? Needing the TerminalEmulator category might seem redundant, but allows ExecArg to be used later on in other specs.

I agree. However this is an additional requirement and I'd suggest to keep them as minimal as possible. On the other hand I can't imagine a use case of ExecArg for non terminals. Id rather add a new key for that potential use case instead of having conditional semantics. This would require a lot of extra wording in the spec that is not strictly necessary.

[alttabber]

I don't think this is a particularly good idea: what if 20 years from now, for whatever reason, someone somewhere needs to use ExecArg for something other than a terminal? Needing the TerminalEmulator category might seem redundant, but allows ExecArg to be used later on in other specs.

I agree. However this is an additional requirement and I'd suggest to keep them as minimal as possible. On the other hand I can't imagine a use case of ExecArg for non terminals. Id rather add a new key for that potential use case instead of having conditional semantics. This would require a lot of extra wording in the spec that is not strictly necessary.

Let's say 15 years from now PWA 2.0 comes out, and allows to distribute applications in a browser-independent way, then we'd have to copy-paste this spec but for PWA 2.0.

[ManuelSchneid3r]

Browser terminals? I don't get it. I dont want to focus this issue that much on this aspect. (Although I think it overcomplicates the spec) Virtually every terminal will have that anyway due to the desktop menu spec.

Let's rather focus on the default that should not be part of the spec.

[alttabber]

Yeah, ExecArg should absolutely be required. A desktop file that does not have it should be interpreted as not supporting the spec, and ExecArg being defined but empty should be interpreted as the terminal simply not needing a flag (foo vim opens vim inside of foo).

Imho, that's the only way to define the spec that makes sense.

[Vladimir-csp]

I would like to keep category condition, because it keeps things tidy.

Why should we be concerned with the current state of upstream? We're making a brand new spec, of course upstream does not support it yet. Upstream has to comply with the spec, not the other way around.

Unfortunately, this spec took a long time to be considered officially, and the implementation made its way into distros, even got used by GNOME, which I was very surprised to learn about. So there is some degree of backwards compatibility to be considered. At least not to break things at implementation level while not breaking the spec too much.

Nothing is more permanent than a temporary solution.

Sad but mostly true. I think I can make it work though, stand by.

And thanks for @ManuelSchneid3r for giving me a hint at a solution and data for implementation.

[ManuelSchneid3r]

Unfortunately, this spec took a long time to be considered officially, and the implementation made its way into distros, even got used by GNOME, which I was very surprised to learn about.

It is still a draft. Ofc some people experiment with it. No reason to carve sth into stone. The only terminal that played around with it is the gnome terminal and its author told me recently that he hopes that xte will not make it. Maybe just because he feels like it's illformed

[ManuelSchneid3r]

I'd suggest to start with a clear and minimal 1.0. No appid and such. A minimal invasive failsafe base. Just the explicit desktop entry key and the lookup specification. Everything else is just too much noise to achieve the main goal: having a consent on how to run a commandline in a user configured terminal.

Keep in mind that we have to convince terminal authors. Once we have an xte spec that made it into upstream sources or distro patches we can further enhance the spec. But for now the core idea should be pushed rather than trying to provide a final spec that covers every potential future use case without the need for any adjustments. Given backward compatibility we can always define a 1.1.

For now the primary goal should be the approval and public acceptance.

[Vladimir-csp]

d1ca54f73272165abbf6bf27895dc251fd74a1e5. Now ExecArg is written as mandatory, but an exclusion for early adoption period is made to define a way to not break things. 4b12048ec4436aa810f2192c5a7925493f782e67 further implements this.

I'd suggest to start with a clear and minimal 1.0. No appid and such. A minimal invasive failsafe base. Just the explicit desktop entry key and the lookup specification. Everything else is just too much noise to achieve the main goal: having a consent on how to run a commandline in a user configured terminal.

I agree. I have doubts about the whole extra args thing, although current state should be in working condition. I have no objections to remove it for 1.0.

[ManuelSchneid3r]

I dont get why we need wording like "Before and during initial adoption phase" and "transition" and such. This spec is still publicly unrecogniced. We dont have to act as if it would break anything while defining it. As @alttabber said, upstream has to comply with the spec, not the other way around. The spec is not approved yet, so we have the full freedom to define and change it as we think it is reasonable.

As said, removing a default that has been specified once is a breaking change. Once a default made it into the desktop entry spec it will (most likely) never be reverted, because this implies that we would have to increase the version of the desktop entry spec to v2.0.

So please remove the wording of a transition and the default for ExecArg in the xte draft entirely.

[Vladimir-csp]

OK, will handle compatibility issues completely outside of the spec ("compat" and "strict" modes in implementation). Caveats will be removed from the Spec.

[adaschma]

From the mailing list :

@ManuelSchneid3r which mailing list are we talking about?

[ManuelSchneid3r]

https://lists.freedesktop.org/archives/xdg/