Re: Desktop Entry Specification: Add new ExecArg key
Vladimir Kudrya <[email protected]> Tue, 16 Jul 2024 11:12:02 +0300
| Newsgroups | gmane.linux.xdg.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------o7SDYw0QNQHSTYXoO7nHLiHj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
We are in the same boat. I'm just pointing out that in the concept of
proposed spec having ExecArg is not always mandatory and having
TerminalEmulator category is mandatory.
On 16/07/2024 10.53, Manuel Schneider wrote:
> I am not arguing against it either. I just want it to happen.
> Preferably soon.
>
> My personal motivation is my app Albert launcher. Currently I need the
> fragile heuristics mentioned before and an in app configuration of the
> user terminal to be used for several actions. This is terribly time
> consuming and impossible to get right. If we had the ExecArg I could
> at least guarantee the functionality of this feature and delegate
> responsibility to desktop entry authors in case of failures.
>
> Ofc I'd prefer your proposal to be merged, because then I could even
> delegate the choice of the terminal to the system. But compared to
> this "convenience" I'd be happy to have it "working at all". But given
> the fact that your proposal lingers around for 5 years I thought we
> could probably speed it up by going step by step. IIUC your proposal
> is a dedicated standard which relies on changes to the desktop entry
> spec. Having this single key added to the desktop spec in near future
> seems to be more realistic. It is a requirement for your proposal
> anyway, so we are in the same boat, aren't we?
>
> Since I am not familiar with the XDG realm I struggle to find out
> where to start a discussion to get things off the ground. You sent
> your PR long time ago. Has there been a discussion or such anywhere?
--------------o7SDYw0QNQHSTYXoO7nHLiHj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>We are in the same boat. I'm just pointing out that in the
concept of proposed spec having ExecArg is not always mandatory
and having TerminalEmulator category is mandatory.<br>
</p>
<div class="moz-cite-prefix">On 16/07/2024 10.53, Manuel Schneider
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
I am not arguing against it either. I just want it to happen.
Preferably soon.
<div><br>
</div>
<div>My personal motivation is my app Albert launcher. Currently I
need the fragile heuristics mentioned before and an in app
configuration of the user terminal to be used for several
actions. This is terribly time consuming and impossible to get
right. If we had the ExecArg I could at least guarantee the
functionality of this feature and delegate responsibility to
desktop entry authors in case of failures.</div>
<div><br>
</div>
<div>Ofc I'd prefer your proposal to be merged, because then I
could even delegate the choice of the terminal to the system.
But compared to this "convenience" I'd be happy to have it
"working at all". <span
style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">But
given the fact that your proposal lingers around for 5 years I
thought we could probably speed it up by going step by step.
IIUC your proposal is a dedicated standard which relies on
changes to the desktop entry spec. Having this single key
added to the desktop spec in near future seems to be more
realistic. It is a requirement for your proposal anyway, so we
are in the same boat, aren't we?</span></div>
<div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br>
</span></div>
<div><font color="#000000">Since I am not familiar with the XDG
realm I struggle to find out where to start a discussion to
get things off the ground. You sent your PR long time ago. Has
there been a discussion or such anywhere?</font></div>
</blockquote>
</body>
</html>
--------------o7SDYw0QNQHSTYXoO7nHLiHj--