Similar to the implementation of the `%f` and `%u` field codes. In this
case the amount of arguments passed poses no problem but the position
could, at least in theory.
This finishes the implementation of all the non-deprecated field codes.
As a part of that, repetitions of field codes are left alone. Originally
all field codes were removed. Now we replace only the first occurence.
This is correct for at least `%f`, `%u`, `%F` and `%U` because at most
one of them is permitted.
Shortcomings:
1. We replace `%[cfFikuU]` patterns one at a time. This means if the
right field code appears as part of the rest of the `Exec` field or
in a field code that was substituted earlier.
2. If any field code is repeated, only the first occurence is
substituted.
`%f` and `%u` are used to signal the program only accepts a single file
or URI argument. I do not believe there's a way to signal this
information to macOS but it is possible the program really won't work if
multiple files are passed and it's possible the relative position of
`%i`, `%c` or `%k` matters. So we replace `%f` or `%u` with `$1`. That
way we only pass one file in the (possibly significant) position of the
field code.
`ls -1 "$iconsdir/"*` listed the source directory for me when the glob
had no matches. Switching to `-A` circumvents this problem and has the
added advantage that it cannot run into argument list length limits.
Checked the desktop entry spec, there's other field codes than `%[fFuU]`
and those can in fact occur more than once, hence dropping '$' and
adding `/g`.
The "Exec" key in desktop items sometimes has one of the `%f`, `%F`,
`%u` and `%U` suffixes, which specify whether the command takes a file,
multiple files or a generalized URL or URLs. Darwin application bundles
do no understand this syntax so we do the next best thing, which is
simply dropping it.
Sometimes scalable icons or icons within the thresholds from the desired
resolutions aren't available. In this case it's still nicer to end up
with a blocky scaled icon rather than the generic default.
In order to compose a `.icns` file containing multiple icon sizes I had
to pass `--toc` to `icnsutil`. This did not seem to have a negative
effect on `.icns` containing only a single icon size.
On macOS 10.13 the 48x48 icon size is not supported. It results in a
corrupted image being displayed. I suspect the image data is being
truncated to what it expects for 32x32 or maybe data is read for
128x128, which would be a buffer overflow.
- Convert icons to a single .icns file; and
- Provide an opt-out via X-macOS-Squircle in the desktop item to
override the squircle behavior when the source icons look bad when
converted automatically.
