The xdg desktop file specification allows for icons to be either a
absolute path just a name. If the name is not an absolute path,
a icon from a icon theme will be used. This commit changes the
desktop file to use a icon name and adds the icons to the default
theme (hicolor). This allows the user to choose an alternative icons
theme that will override the default icon.
The relevant specs:
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
> Icon to display in file manager, menus, etc. If the name is an
> absolute path, the given file will be used. If the name is not
> an absolute path, the algorithm described in the Icon Theme
> Specification will be used to locate the icon.
https://specifications.freedesktop.org/icon-theme-spec/latest/ar01s07.html
> Installing Application Icons: [...] Minimally you should install a
> 48x48 icon in the hicolor theme. This means installing a PNG file
> in $prefix/share/icons/hicolor/48x48/apps.
https://specifications.freedesktop.org/icon-theme-spec/latest/ar01s03.html
> Icons and themes are looked for in a set of directories. By
> default, apps should look in $HOME/.icons (for backwards
> compatibility), in $XDG_DATA_DIRS/icons and in
> /usr/share/pixmaps (in that order).
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables
> $XDG_DATA_DIRS defines the preference-ordered set of base
> directories to search for data files in addition to the $XDG_DATA_HOME
> base directory. The directories in $XDG_DATA_DIRS should be
> seperated with a colon ':'.
> If $XDG_DATA_DIRS is either not set or empty, a value equal to
> /usr/local/share/:/usr/share/ should be used.
When deciding which methods to export, `iconv-lite` verifies the
availability of some Node features, which is clearly an unsupported
behavior when executing it via `mksnapshot`.
In this case we were not getting any exception at compile-time, but we
noticed some methods were missing from iconv-lite's API. With this
commit we are excluding this module from the snapshot, thus making all
of its methods available again.
Previously, a spurious '*' in these regexps would cause them to match anything in
the containing modules' src folder. This caused problems for modules like
oniguruma that have JavaScript files in the src folder.
Also, we were shipping superstring's C++ code because we forgot to add it to
the blacklist. I think it's safe to say we don't want to ship any C++ code
at all.
