Binary name in the desktop file

[Kevin Krammer]

On Friday, 2013-12-27, 15:24:43, Jerome Leclanche wrote:
> On Fri, Dec 27, 2013 at 3:01 PM, Kevin Krammer <krammer at kde.org> wrote:
> > On Thursday, 2013-12-26, 15:34:03, Jerome Leclanche wrote:
> >> I'm sorry, you're right. I should have been clearer.
> >> 
> >> I need this functionality for intents, but I was just trying to
> >> display that I'm not the only one actually needing it (and that it's
> >> not just theoretical).
> > 
> > I have to admit I didn't follow that closely enough, but wouldn't the
> > program authors have to specify the invocation for intents instead of
> > relying that the program without arguments is the correct one?
> 
> Not specifically - intents don't inherently run a program any more
> than the shared-mime-info spec does. They only determine which
> programs should be ran.
> For DBus-activatable apps this is a non-issue of course but not all
> programs are like that.

Ah, I see. I thought that apps might have to be aware that they are launched 
via intents.

> >> Currently, Wine creates the sort of desktop
> >> files I pasted in the original post. This causes runners (like
> >> lxqt-runner) to think those programs should be displayed when you
> >> start writing "env" (they are completely irrelevant and the use of
> >> "env" is an implementation detail).
> > 
> > Hmm. I guess if you type "env" you would like to have /usr/bin/env as a
> > suggestion, no?
> > The runner that searches $PATH would detect that already.
> > 
> > If there is a runner that gives suggestions on .desktop file Exec lines
> > then those are relevant hits as well.  I would have guesses that the
> > .desktop runner only checks name and description though, since the
> > command line is usually hidden from the users and wouldn't tell them
> > anything.
> 
> Yup, all well and good, and the current behaviour on the runner's side
> is the correct one. However you're unlikely to want nearly every Wine
> app if you type in "env". Currently, /usr/bin/env is the only way to
> modify the environment for the program being ran, which creates this
> conflict.

I would find it weird if a .desktop runner source would look into Exec lines 
since those are highly irrelevant to the user. So an input of "env" would only 
show the env binary as it is found in $PATH.

> >> I guess it is too late to fix it, but my backwards-compatible proposal
> >> would do the job for apps that care about it. If it's missing, we just
> >> assume the app starts the same way with and without args.
> > 
> > I don't think it is, there is always room for improving the spec.
> > 
> > After thinking about it a bit more the name ExecNoArgs might be a bit
> > confusing. The command line specified in it could very well have
> > arguments,
> > just no variables.
> > 
> > Also, if present but empty, that could be treated as "cannot be launched
> > without file/urls".
> 
> Agreed on the name; I don't like it either I just needed a clear example.
> I don't think it's too late to fix the spec from an implementation
> point of view, but it does feel like it's too late to convince people
> this is worth the modification (and I don't have time to defend tooth
> and nail fixes to all my pet peeves).

A specification, or an extension of one, needs to address a use case. That use 
case needs to be well understood, otherwise it will be hard or even impossible 
to write the respective spec text properly and/or unclear how it should be 
used or implemented.

I think the use case is quite clear now [1], but got buried in the totally 
unrelated environment discussion.

> The "present but empty" functionality has interesting potential.

That is something that would have to be evaluated/discussed, otherwise we 
might end up needing yet another extension.

Cheers,
Kevin

[1] A launcher, e.g. app menu, needs to be able to launch an application 
without providing and values for Exec line variable substitutions.
Applications for which the Exec line with all variables relaced with nothing 
is not the appropriate launch command, need to specify a separate Exec like 
key named ....

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20131227/ae2c2af3/attachment.pgp>