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

[Jasper St. Pierre]

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.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20131231/0eaccb5f/attachment.html>