Setup the general font cache in the desktop extensions using an
extension provided configure
hook to cache the system fonts and let
the launcher only process user fonts (e.g.; .fonts
) to decouple font
caching issues found on many systems and offload first run times to
the system (e.g.; snapd install and refreshes).
The cross distro story shall benefit from decoupling font processing from the system as there will be no more font cache misses due to cache ABI changes between the cache generation logic found within the snap and that found on the system.
The fonts.conf
file shall be modified to achieve fallback
mechanisms.
When the configure
hook runs it must run fc-cache
to update the fonts
cache with from fonts that are generally available on the system using
a privately generated fonts.conf
. This cache must reside in a location
that is generally available to the snap when run by a desktop user, to
achieve such result, the cache shall reside in $SNAP_DATA
.
When the desktop application launches, the launcher generated by the
extension shall contain a reference to this cache and only process
fonts that are installed on the user’s private font instance, ~/.fonts
.
The desktop extensions require changes in two of its components, the
desktop parts that generate the required command-chain shall generate
a new command-chain
proper for the configure
hook that will generate
the system fonts cache.
The fonts.conf
that shall be written on hook run (to allow for future
modification) and referenced by fc-cache
shall look as follows:
<fontconfig>
<cachedir>$SNAP_DATA/fontconfig</cachedir>
<include ignore_missing="yes">/etc/fonts/fonts.conf</include>
</fontconfig>
The YAML generated by the desktop extensions shall be extended to add
a hook
entry that references this new command-chain
, such that the
following is generated:
hooks:
configure:
command-chain:
- snap/command-chain/snapcraft-runner
- snap/command-chain/hooks-configure-desktop
plugs:
- desktop
Logic must be added to support running a command-chain
for a hook when
no hook was provided by the snap developer, Snapcraft must support the
scenario where a command-chain
for a hook was defined in
snapcraft.yaml
but no hook was provided.
To achieve this result and considering the current logic existing in
Snapcraft’s meta
package is that Snapcraft shall generate a stub for a
hook for when it finds command-chains
in hooks which shall be
overwritten by actual hooks.