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

[Jerome Leclanche]

On Tue, Dec 31, 2013 at 11:05 AM, David Faure <faure at kde.org> wrote:
> 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.

So that detail should be in the menu spec, not the desktop file spec.
I see no mention of TryExec in
http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

In my mind, desktop files are as declarative as possible; and so, the
desktop file spec should not dictate implementations as that is
completely counter-intuitive. Maybe the TryExec key can be used to
hide files in the menu spec, and maybe it can be used for something
completely different in another. The former usage is only relevant to
the menu spec.

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

I see what you're saying but this is one of those things that should
be down to the app developer to make sure they don't litter their
users' setup.

J. Leclanche

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