With `IconPath`, you can override the icon used for the application
shortcut. This currently only supports resolving the icon through
`GUI::FileIconProvider`, the implementation for pointing to actual
image files is left as an exercise for the reader.
This is common enough to warrant its own setting by now - but it's also
partially a workaround. Since app files currently only support a single
executable path with no arguments, we resort to generating wrapper
scripts for port launchers with arguments - and then the executable is
that shell script. We also moved from manually specifying icon files to
embedding them in executables. As shell scripts can't have icons
embedded in them, a different solution is needed - this one solves the
common case of running a CLI program in a terminal, and still allows
embedding of icons in the executable itself as no shell script is
needed, meaning it will be shown in the taskbar and system menu.
The second use case of actually passing arguments to the executable
itself (and not just "Terminal -e ...") is not covered by this and still
requires an external script (meaning no icon for now), but I think that
can easily be solved by adding something like an "Arguments" field to
app files. :^)
This changes client methods so that they return the IPC response's
return value directly - instead of the response struct - for IPC
methods which only have a single return value.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
IPC::Connection::send_sync asserts that a response was received, so the
current gracefull fail check was useless, as LibIPC would always assert
before reaching it.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
