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

David Faure faure at
Sun Feb 2 01:59:17 PST 2014

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> wrote:
> > On Tue, Dec 31, 2013 at 6:12 AM, Jerome Leclanche <adys.wh at> 
> >> So that detail should be in the menu spec, not the desktop file spec.
> >> I see no mention of TryExec in
> >>
> > 
> > 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,
Working on KDE, in particular KDE Frameworks 5

More information about the xdg mailing list