On Tuesday 31 December 2013 11:00:23 Jerome Leclanche wrote: > On Tue, Dec 31, 2013 at 10:55 AM, David Faure <fa...@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, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg