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

[Jerome Leclanche]

On Tue, Dec 31, 2013 at 4:20 PM, Jasper St. Pierre
<jstpierre at mecheye.net> wrote:
> On Tue, Dec 31, 2013 at 6:12 AM, Jerome Leclanche <adys.wh at gmail.com> wrote:
>>
>> 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
>
>
> Speaking with my GNOME hat on, GNOME is now ignoring the menu spec upstream,
> in favor of allowing the user to create their own categories and folders in
> the GNOME Shell Overview.
>
> Personally, I do not feel the menu-spec should be extended anymore, or
> considered something we recommend to OEMs.
>
>>
>> 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.
>
>
> I strongly feel that TryExec should be well-defined and used for hiding
> apps. Otherwise, we don't really have a specification, we just agree that
> TryExec is a key that contains a path, and maybe it will hide apps when it
> doesn't exist, and maybe it will launch green army men to the moon when it
> doesn't exist.
>
> There are plenty of cases where we don't use the menu-spec at all, but need
> to launch apps. One simple example is the "Open With..." prompt in
> Nautilus/Files: we show a list of apps to the user, and need to run TryExec
> by the standard. menu-spec was not involved here.
>

Wouldn't it make more sense to keep the TryExec key, and have an
additional key to define the behaviour if TryExec is missing?

You could have something like:

gmail.desktop
TryExec=firefox
MissingExecutable=X

where X could be ignore (default), hide (current behaviour) or even
something like delete, where the desktop file would be deleted
altogether (if that is possible) if the TryExec is missing.

Or you could just have a boolean key HideIfMissing=true, defaulting to either.

J. Leclanche

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