This caches GAppInfo so that the compositor thread does not have to perform
costly disk access to load them. Instead, they are loaded from a worker
thread and the ShellAppCache notifies of changes.
To simplfy maintenace, ShellAppCache manages this directly and the
existing ShellAppSystem wraps the cache. We may want to graft these
together in the future, but now it provides the easiest way to backport
changes to older Shell releases.
Another source of compositor thread disk access was in determining the
name for an application directory. Translations are provided via GKeyFile
installed in "desktop-directories". Each time we would build the name
for a label (or update it) we would have to load all of these files.
Instead, the ShellAppCache caches that information and updates the cache
in bulk when those change. We can reduce this in the future to do less
work, but chances are these will come together anyway so that is probably
worth fixing if we every come across it.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/2282
A number of things can result in doing I/O on the main thread such as
loading GAppInfo or folder translations. The ShellAppCache provides a
layer of abstraction around those things so that we can keep that work
off the main thread by delaying a short while and processing the work
synchronously off-main-thread.
The results can then be marshalled back to the main thread for use by
the rest of the system via the ShellAppCache::changed() signal.
