Binary name in the desktop file

Kevin Krammer krammer at
Fri Dec 27 07:01:26 PST 2013

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?

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

> I should probably have written two separate mails for this but this
> seemed relevant. Anyway, that specific use case is fixed with an
> Environment key, which would be easy enough to implement (and
> backwards compatibility would be unharmed).

Sure, though I am not convinced that it is necessary, mostly because it is 
only one of potential runtime requirements.
A start script can easily deal with environment setup additional to any other 
setup stage, e.g. launching a service. It can even make decisions on the 
already existing environment, like the user as Ma Xiaojun mentioned.

Anyway, not really related to the No Args use case.

> More generic:
> desktop files make the assertion that starting a program is inherently
> the same *with* and *without* arguments. This is declaratively very
> annoying, because it prevents programs from having a different command
> line for args / no args.

True, good point.

> 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".


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: <>

More information about the xdg mailing list