Binary name in the desktop file

[Jerome Leclanche]

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

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


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. I'm surprised this hasn't been done before
since the desktop files are shared between, for example, menus/runners
and xdg-open. Maybe it's my nature of never trusting user (in that
case: application developer) input kicking in, but it means that an
app that would expect different syntax with and without args will not
work in one of the cases, and there is no way to fix it (other than
working around it at the application level, which is frankly not
something xdg should be dictating).
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.

J. Leclanche


On Thu, Dec 26, 2013 at 3:10 PM, Kevin Krammer <krammer at kde.org> wrote:
> On Thursday, 2013-12-26, 14:46:13, Jerome Leclanche wrote:
>
>> I'm somewhat losing track of what's actually being said here.
>
> Yes, sorry.
>
> This particual sub thread discusses why you need a special solution in the
> first place.
>
> For example the snippet you posted had clearly /usr/bin/env as the command,
> but somehow this is not the one you are expecting.
> This lead to the assumption that you are either expecting wine or start.exe to
> be the one you'd like to have.
>
> In both cases the .desktop file is using hacks or helpers to ensure the
> required runtime for the actual command.
>
> So we were discussing proper ways of ensure that command in the Exec line is
> actually the command and ensures itself that its runtime requirements are met.
>
> In both possible alternative cases, i.e. independed of whether you consider
> wine or start.exe to be the target command, an appropriate start script would
> have solved that without requiring any extra support in either spec or
> launchers.
>
> E.g. a wine.sh that gets
> start /ProgIDOpen chm.fie.%f
> as its arguments in the case of wine being the actual target command
>
> or start.exe.sh that gets
> /ProgIDOpen chm.file %f
> as its argument in case of start.exe being the actual target command.
>
> In other words avoiding the problem to exist in the first place instead of
> trying to work around it.
>
> 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
>