With everything now using GUI::FileIconProvider and therefore loading
icons embedded in the executable files, this information is now longer
being used.
We might have to think about this again if we want to allow .af files
with custom commands (e.g. shell scripts). Maybe those could get away
with just an "Icon" entry under "[App]", but currently there's only
"Executable" anyway.
Browser supports very few protocols (http, https, gemini, file) at the
moment, so there's no point in using it as a catch-all and default
protocol handler. I added an explicit association for gemini to
/bin/Browser instead.
This stops Desktop::Launcher::open() from reporting success for any URL,
which really isn't the case (Browser shows an error page...).
Adds metadata about apps for what file types and protocols they can
handle, then consumes that in the LaunchServer. The LaunchServer can
then use that to offer multiple options for what apps can open a given
URL. Callers can then pass back the handler name to the LaunchServer to
use an alternate app :)
The new system directory /res/apps now contains ".af" files describing
applications (name, category, executable path, and icon.)
These are used to populate the system menu with application shortcuts.
This will replace the Launcher app. :^)
