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

[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


On Sun, Dec 29, 2013 at 1:05 PM, Thiago Macieira <thiago at kde.org> wrote:
> On domingo, 29 de dezembro de 2013 11:15:23, Jerome Leclanche wrote:
>> 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"?
>
> 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?
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>