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

[David Faure]

On Tuesday 31 December 2013 16:48:30 Jerome Leclanche wrote:
> 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.

This looks like a solution in search of a problem.
"ignore" the same as not having a TryExec key at all, "hide" is what we have, 
and "delete", well, I certainly wouldn't want to enable a feature that deletes 
my carefully crafted .desktop file because of a typo in TryExec. (and system 
desktop files are typically not deletable, so this is indeed really only about 
user desktop files)

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