Desktop file spec improvements (was: Binary name in the desktop file)
adys.wh at gmail.com
Tue Dec 31 03:00:23 PST 2013
On Tue, Dec 31, 2013 at 10:55 AM, David Faure <faure at kde.org> wrote:
> On Tuesday 31 December 2013 05:44:12 Ryan Lortie wrote:
>> On Tue, Dec 31, 2013, at 5:39, David Faure wrote:
>> > It is missing in many many
>> > .desktop
>> > files, but this means solving this doesn't require a change in the spec,
>> > it
>> > only requires everyone to add that TryExec key in most desktop files.
>> TryExec has a negative performance implication: you must do at least one
>> stat call (and possibly several in the case that you are searching the
>> path) in order to find out if the desktop file should be shown or not.
>> With the desktop file index in place, this turns out to be the single
>> most-expensive thing that we have to do when listing off all desktop
>> files. In light of this, I'd generally advise people to _avoid_ adding
> OK then we need a different key indeed :)
> One that contains the name of the executable that has to be present on disk so
> that, *after* trying to launch a program and it fails, we can check if the
> binary actually exists, in order to give the user a proper error message.
> This doesn't have the performance impact you mention, since it's only done on
> error, after the fact.
I disagree. I don't think the desktop file spec should dictate whether
TryExec is run after or before Exec, it should be an implementation
detail (and so the performance trade-off should be up to the
developer). It's silly to have a key and say "We recommend against
> So I am in favour of a ExecutableFile=firefox which can be
> ExecutableFile=/usr/something/foo.jar or any other file that is required for
> running this desktop file.
> But again, this is not something anyone should try to "execute" as is.
> I hope the naming of the key is clear enough, otherwise a better name could be
> Hmm, for the case of wine or java, there are actually two requirements,
> wine/java and then the .exe/.jar. So maybe this could be
> and for simpler cases, of course,
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg