Desktop file spec improvements (was: Binary name in the desktop file)

[David Faure]

On Tuesday 31 December 2013 11:00:23 Jerome Leclanche wrote:
> 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:
> >> hi,
> >> 
> >> 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
> >> TryExec.
> > 
> > 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
> it".

Not at all. The spec is clear: the purpose of TryExec is to hide desktop files 
from the menu if a given executable is not installed. In the cases where this 
has good chances of happening, the key makes a lot of sense, and should be 
kept and used.

But in many many cases the executable and the .desktop file are installed by 
the same package, and therefore it's wasteful to check for the presence of the 
executable. The only case where it would be missing would be if the user 
manually removed it - a corner case that is not worth our CPU cycles.

TryExec makes sense for the case where the .desktop file comes from elsewhere. 
For instance, when we had .desktop files for the X screensavers. No point in 
offering them to the user if the executables are not installed.
Same for any other case of "a DE installing desktop files for something that 
doesn't ship them themselves".

So there is a valid use case for TryExec, but indeed we shouldn't recommend 
every application to use it, that would be wasteful and unnecessary.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5