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

[Jerome Leclanche]

I'm editing the subject because we seem to be going back and forth on
different points and it's leading to serious confusion.

I remember TryExec now. TryExec partly fits one of my needs, although
there remains the issue of starting without args.
Starting without args is something a lot of xdg implementers do:
Menus, application runners, launchers... All of these assume that
%F/%f/%U/%u can safely be replaced by an empty string. We all know
this isn't always the case. Now, can "this isn't the case" be
considered an application bug? Let's put it this way: would you be
comfortable telling people "The entire way your application is run
(possibly even on all platforms you support) is broken because the xdg
spec wants it this way"?
Keep in mind: the desktop file is not always written by the app's
developers. More often than not, packagers/maintainers write it and
have to deal with a dead or unresponsive upstream.

I think *why* I want it is not completely relevant, as there is a
current need for it anyway. However, let's explain, and if you reading
this would please bear with me because I will not in this thread go in
details about intents (I will post about them another day).
For intents, I extend the concept of launching an application to more
than just "Start an app and probably open some files with it".
Specific application behaviour is involved. I have given an example
earlier with IDEs; as Thiago put it, you can call these bits
"actions". There is in fact an existing Action key which partly
represents that concept and a couple of apps create very nice example
intents with it (it ideally is something I will extend, however that
will involve pretty severe changes in the desktop action spec - I will
go into this another time).
So as you can imagine, what is currently rare enough not to really
warrant caring about suddenly becomes more common. I don't have any
clear examples of this off the top of my head, however you need to
keep in mind that an action, just like the desktop entry itself, can
just as well be with or without args or both.

When I originally wrote my email I made one major mistake which was
obvious in hindsight; running without arguments is not necessarily the
same as the binary's name.
The latter is, imho, well-enough solved by TryExec. You mention the
bit about hiding the desktop file and i double-checked the specs to be
sure:
"Path to an executable file on disk used to determine if the program
is actually installed. If the path is not an absolute path, the file
is looked up in the $PATH environment variable. If the file is not
present or if it is not executable, the entry may be ignored (not be
used in menus, for example)."
Language used: "may". Of course, the autostart spec uses MUST NOT but
that makes a lot more sense for obvious reasons. At this point, I
think if you want a TryExec key that does not hide the icon when
unresolved, I would probably go for an X-KDE-AlwaysShow or something.

So, no, I don't want the desktop file's binary name (and I think we
should implement a %e token in the Exec key that would be replaced
with the contents of TryExec, for the sake of DRY; that's another
story again, even if it makes a lot more sense than, say, "The Icon
key of the desktop entry expanded as two arguments" - note: I have
some ideas on how to improve that too, but that would just divert the
discussion even more which I dont want to do right now).

I still want a "NoArgs" key to start an app without arguments, and I
haven't been given a reasonable alternative so I am currently bound to
think it does not exist. I haven't looked too closely at dbus
activation so I can't speak to that yet, please do let me know if I'm
missing something here.

J. Leclanche

I'd really like to be able to get the binary name from desktop files
(eg a way to "start without any argument").

You didn't say why.
I don't think all programs can be started without arguments - your example
with "wine" is a good example of that. Other programs might do something
completely different when started without arguments, which might not be wanted
(but of course you could say that in that case they don't provide such a key,
and then they never get started without arguments....). So, maybe you need
this to be much more precise, if the intended use case is "start the program
and wait for it to register to DBus and then talk to it"... then the key in
the desktop file would be something like DBusActivationBinary=...
In fact, I could use a "binary name" key in desktop files, too, for the
* to extract the BIN= value for the startup notification standard (not sure
what this is then used for...). Seems at least to be used as default value for
the icon and for WMClass, if these are not specified.
* to check for "executable not found" when launching an executable from a
.desktop file and it fails (the process exits with an error code). When that
happens, I extract the binary name from the Exec line (yes, with all the
syntax pitfalls that this might have), look for it in $PATH, and if it can't
be found, I can then show a gui error message "Could not find the program
<foo>", which is much better than nothing happening at all from the user's
point of view.
A field for the executable name would make this more reliable.
This is a bit like TryExec, except that TryExec hides the desktop file if the
executable can't be found, which isn't always wanted (e.g. you don't want that
for an icon you explicitely added to your desktop or panel).
But note that my purpose isn't starting the executable without arguments, only
looking for it in PATH. So this one could be set for wine too, which is
another reason for the "dbus activation binary" to be separate from the
"here's the binary to check in PATH"....
--
Working on KDE, in particular KDE Frameworks 5

[Thiago Macieira]

Post by Jerome Leclanche
I remember TryExec now. TryExec partly fits one of my needs, although
there remains the issue of starting without args.
Menus, application runners, launchers... All of these assume that
%F/%f/%U/%u can safely be replaced by an empty string. We all know
this isn't always the case. Now, can "this isn't the case" be
considered an application bug? Let's put it this way: would you be
comfortable telling people "The entire way your application is run
(possibly even on all platforms you support) is broken because the xdg
spec wants it this way"?

Maybe we can fix this in another way, for most of the cases. Not all, though.

Suppose we have:

Exec=appname --file=%f

If this .desktop file is present in the menu, it will be launched by running on
the command-line:
appname --file=

Which may or may not do the right thing. The right thing might be to run
withou the --file= argument. We have three choices here:

1) declare that "text%f" should be removed if %f is also empty
=> drawback: in some cases, we may want to keep the text
=> question: do we even recognise the %f for expansion if it's not
surrounded by spaces?

2) extend the syntax, such as: %{f+--file=%f}, similar to a shell expansion
=> solves the drawback above but doesn't catch the corner case below

3) add a completely separate desktop keyword for running with no files, like we
have done for TryExec.
=> advantage: supports weird things like:
Exec=appname --open --file=%f
ExecNoArgs=appname --newproject

(although we could also "uglify" the syntax and do:
Exec=appname %{f+--open --file=}%{f---newproject})

Jerome, is the #3 case what you're aiming for? And do you have a concrete
example that requires it?

[Jerome Leclanche]

Yes, #3 was what I was aiming for. You brought some interesting other
solutions to the table (all of which are backwards incompatible
unfortunately), but they give me the occasion to present something I
said I didn't want to mention quite yet but it seems relevant now.

Preface: Currently, %i is replaced by "--icon <Icon key>"; if there is
no icon, it's replaced by an empty string altogether. This is, for
hundreds of obvious reasons, stupid but it's also obvious why it was
done that way.

What I thought could be done instead of that was a key where you could
define replacements for the various keys. The replaced entities would
be empty strings if the original entity didn't exist. That same
concept can nicely solve nearly every corner case with arguments and
other potential desktop file keys.

Say, an ExecTokens key would take in a list (semicolon-separated
values) of key/value pairs, where the key is a % token and the value
is what that % token is to be replaced by, including possibly other %
tokens.

For example, the current %i behaviour would be re-implemented as:

ExecTokens=%i=--icon %i;
Exec=foo %F %i

If the icon key does not exist, it is replaced by an empty string.
Otherwise, it is replaced by the *formatted* contents of the %i key in
ExecTokens. If the ExecTokens key is empty, or does not contain the
relevant token, default behaviour ensue (nicely backwards-compatible).

This allows neat new possibilities where for example you can do something like:

ExecTokens=%f=--file %f --icon %i;

As such, if the default value of %f would not be an empty string, it
would be replaced by --file <file> --icon <icon or empty string>.

It's just a quick brainstorm right now and there's some glaring
undefined behaviour that would need to be figured out but it seems
like a sensible idea.
J. Leclanche

Post by Thiago Macieira

Post by Jerome Leclanche
I remember TryExec now. TryExec partly fits one of my needs, although
there remains the issue of starting without args.
Menus, application runners, launchers... All of these assume that
%F/%f/%U/%u can safely be replaced by an empty string. We all know
this isn't always the case. Now, can "this isn't the case" be
considered an application bug? Let's put it this way: would you be
comfortable telling people "The entire way your application is run
(possibly even on all platforms you support) is broken because the xdg
spec wants it this way"?

Maybe we can fix this in another way, for most of the cases. Not all, though.
Exec=appname --file=%f
If this .desktop file is present in the menu, it will be launched by running on
appname --file=
Which may or may not do the right thing. The right thing might be to run
1) declare that "text%f" should be removed if %f is also empty
=> drawback: in some cases, we may want to keep the text
=> question: do we even recognise the %f for expansion if it's not
surrounded by spaces?
2) extend the syntax, such as: %{f+--file=%f}, similar to a shell expansion
=> solves the drawback above but doesn't catch the corner case below
3) add a completely separate desktop keyword for running with no files, like we
have done for TryExec.
Exec=appname --open --file=%f
ExecNoArgs=appname --newproject
Exec=appname %{f+--open --file=}%{f---newproject})
Jerome, is the #3 case what you're aiming for? And do you have a concrete
example that requires it?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Thiago Macieira]

Post by Jerome Leclanche
Yes, #3 was what I was aiming for. You brought some interesting other
solutions to the table (all of which are backwards incompatible
unfortunately)

Why would they be backwards incompatible? % followed by { isn't currently
handled today, we can just define what it should be.

[Ryan Lortie]

hi,

Post by Thiago Macieira

Post by Jerome Leclanche
Yes, #3 was what I was aiming for. You brought some interesting other
solutions to the table (all of which are backwards incompatible
unfortunately)

Why would they be backwards incompatible? % followed by { isn't currently
handled today, we can just define what it should be.

The problem comes when people start adding these new expansions to their
desktop files and expecting those desktop files to work with existing
implementations that have no idea what they're talking about.

For this reason, more than anything else, I think that use of a wrapper
script (or redesigning of the program to be executed) will be more or
less required in all cases. This is the same reason that we tell people
to always have en Exec= line even if DBusActivatable=true. You cannot
rely on the implementation to understand these advanced features.

But let's say we want to look forward to a world where we can
simultaneously support having the wrapper script for backward
compatibility while also allowing direct launching of the executable in
order to avoid the script for implementations that know how to do so.

Of course, we'd need to leave the wrapper script in the Exec= line for
the stated reasons of compatibility.

Now we have to add two new keys:

ExecWithNoFiles=
ExecWithFiles=

and as you pointed out in your previous email, we'd probably want some
fancy expansions for the ExecWithFiles= line such as --file=%f or
%{f+--file=%f}.

Strictly, I guess those two entries could be combined into a new
SuperExec= entry that is only used if the new expansions are understood,
assuming we make the expansions powerful enough to deal with the
files-vs-nofiles case properly. Note that this would have to include
the possibility of *separate* arguments, as in:

app --file a --file b

or maybe even:

app --open-file a

vs.

app --new

so that could be a tall order indeed.

So the proposed solution starts to look like:

- not universally supported
- (...and therefore) still need to write and install a wrapper script
for Exec=
- need at least one (probably two) new desktop file entries
- need powerful/complex new expression language for argument expansion


To me this looks like a really large amount of added complexity for
little gain. Namely: we still need to have a wrapper written and
installed. In the case that the thing reading the desktop file
understands the new SuperExec= line, the only advantage is that we avoid
running a bit of shell. If the particular usecase here is that we're
starting wine, that bit of shell is really lost in the noise.

Another possibility: install two desktop files. Make one of them
NoDisplay with declared mime types and have its Exec= line be the one
for opening a file. Mark the other one as supporting no mime types, but
being displayed and use its Exec= line for starting the app without a
file. This some disadvantages in terms of app matching, but if this is
for wine, I suspect you're already losing there anyway.

Cheers

[David Faure]

Post by Ryan Lortie
To me this looks like a really large amount of added complexity for
little gain.

I agree.

Plus, having two complex commands in ExecWithNoFiles and ExecWithFiles
doesn't even help "looking up applications by executable name" (the use case
shortened as "runners" earlier).

Post by Ryan Lortie
Another possibility: install two desktop files. Make one of them
NoDisplay with declared mime types and have its Exec= line be the one
for opening a file. Mark the other one as supporting no mime types, but
being displayed and use its Exec= line for starting the app without a
file.

Exactly. This is the existing and working solution for the "--file %f" issue.


Jérome, this is exactly why we've all been asking "which problem are you
trying to solve exactly", because the solutions differ depending on the actual
problem. It's not fair to get frustrated because we're trying to understand
what you're actually trying to solve here.

The problems I do see (matching desktop files by executable name, and checking
if the executable exists before or after attempting to execute the Exec line)
can both be solved with a TryExec key. 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.

[Ryan Lortie]

hi,

Post by David Faure
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.

Cheers

[David Faure]

Post by Ryan Lortie
hi,

Post by David Faure
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.

So I am in favour of a ExecutableFile=firefox which can be
ExecutableFile=/usr/something/foo.jar or any other file that is required for
running this desktop file.

But again, this is not something anyone should try to "execute" as is.
I hope the naming of the key is clear enough, otherwise a better name could be
found.

Hmm, for the case of wine or java, there are actually two requirements,
wine/java and then the .exe/.jar. So maybe this could be
RequiredFiles=wine;/c/programs/foo.exe;
RequiredFiles=java;/usr/something/foo.jar;
and for simpler cases, of course,
RequiredFiles=firefox

[Jerome Leclanche]

Post by David Faure

Post by Ryan Lortie
hi,

Post by David Faure
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".

Post by David Faure
So I am in favour of a ExecutableFile=firefox which can be
ExecutableFile=/usr/something/foo.jar or any other file that is required for
running this desktop file.
But again, this is not something anyone should try to "execute" as is.
I hope the naming of the key is clear enough, otherwise a better name could be
found.
Hmm, for the case of wine or java, there are actually two requirements,
wine/java and then the .exe/.jar. So maybe this could be
RequiredFiles=wine;/c/programs/foo.exe;
RequiredFiles=java;/usr/something/foo.jar;
and for simpler cases, of course,
RequiredFiles=firefox
--
Working on KDE, in particular KDE Frameworks 5
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[David Faure]

Post by Jerome Leclanche

Post by David Faure

Post by Ryan Lortie
hi,

Post by David Faure
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.

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.

[Jerome Leclanche]

Post by David Faure

Post by Jerome Leclanche

Post by David Faure

Post by Ryan Lortie
hi,

Post by David Faure
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.

Post by David Faure
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

Post by David Faure
--
Working on KDE, in particular KDE Frameworks 5

[Jasper St. Pierre]

Post by Jerome Leclanche
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.

Post by Jerome Leclanche
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.

Post by Jerome 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

Post by Jerome Leclanche
be down to the app developer to make sure they don't litter their
users' setup.
J. Leclanche

--
Working on KDE, in particular KDE Frameworks 5

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jerome Leclanche]

On Tue, Dec 31, 2013 at 4:20 PM, Jasper St. Pierre

Post by Jerome Leclanche
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.

Post by Jerome Leclanche
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

Post by Jerome 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

--
Working on KDE, in particular KDE Frameworks 5

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

--
Jasper

[David Faure]

Post by Jerome Leclanche
On Tue, Dec 31, 2013 at 4:20 PM, Jasper St. Pierre

Post by Jasper St. Pierre

Post by Jerome Leclanche
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.

Post by Jerome Leclanche
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?
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)

[Ryan Lortie]

hi,

Post by David Faure
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.

This is exactly correct.

Cheers

[Dominique Michel]

Le Sun, 29 Dec 2013 11:15:23 +0000,

Post by Jerome Leclanche
I'm editing the subject because we seem to be going back and forth on
different points and it's leading to serious confusion.
I remember TryExec now. TryExec partly fits one of my needs, although
there remains the issue of starting without args.
Menus, application runners, launchers... All of these assume that
%F/%f/%U/%u can safely be replaced by an empty string. We all know
this isn't always the case. Now, can "this isn't the case" be
considered an application bug? Let's put it this way: would you be
comfortable telling people "The entire way your application is run
(possibly even on all platforms you support) is broken because the
xdg spec wants it this way"?ay the app's
developers. More often than not, packagers/maintainers write it and
have to deal with a dead or unresponsive upstream.
From my experience as both upstream and packages maintainer, that's not

true. I write ebuilds for the gentoo pro-audio overlay, and each time I
contacted upstream about missing or non compliant desktop files, I
always get very good responses, and at the exception of only one case,
the fixes I suggested, or some variant, was included into the next
release. The same is also true for less obvious issues. In general,
upstream like very much when a package maintainer or an user show them
he care about their software by reporting an issue.

In fact, lack of communication is a real issue with distributions
developers. Very few of them take the initiative to contact upstream
when they can solve a problem themselves, and much more often than
the inverse, the only mean I have to know their concerns with the 2
projects I am managing is to search for distributions related bugs with
google. Hopefully, it is not many of them.

With users, that's more complicated because many of them are less
skilled than developers, and their reports can sometime be very
confuse, which can make hard to figure out what is going on.

For the rest, I will just follow the discussion.

Dominique