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 <kram...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg > _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg