Binary name in the desktop file

[Jerome Leclanche]

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.

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

Yeah, as I said earlier I should have written two separate emails as
those bits are only loosely related.
The way I see it, there is an existing runtime requirement of
modifying the environment (and if you think about it for a bit, it's
not surprising). I would cast a strong vote in favour of an
Environment key to solve that issue.
systemd's service files are a good glimpse of various requirements on
an app's side. Of course they are more thorough as more than just
startup is required (systemd also wants shutdown and reload/restart
and has a heap more functionality), but some of it overlaps and this
is a good example of one I'd say.

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

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

The "present but empty" functionality has interesting potential.

>
> Cheers,
> Kevin
>
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>

J. Leclanche