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


On Sun, Dec 29, 2013 at 9:27 AM, David Faure <faure at kde.org> wrote:
> On Thursday 26 December 2013 10:56:11 Jerome Leclanche wrote:
>> 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
> following use cases:
>
> * 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"....
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>