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

[Ryan Lortie]

hi,

On Sun, Dec 29, 2013, at 8:52, Thiago Macieira wrote:
> On domingo, 29 de dezembro de 2013 13:35:31, Jerome Leclanche wrote:
> > 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