That’s something we think is going to be needed to get themes to work.

Indeed the way GTK/GNOME works we need to make the theme available under
$share/theme/<theme_name>. Since we don’t know in advance what theme the
application is going to need we don’t know what directory to create at
build time (or we would need to create empty directories for all the
existing themes and rebuild every time a new theme is uploaded to the
store, and that would not cover locally built theme snaps).

Here is an example of the proposed definitions in case it helps
understanding the problem

if we’re only targeting classic, would it be acceptable to only support the themes installed on the base system?

do we care about themes installed into the user’s home directory?

are those themes going to be usable by confined apps?

If we only wanted to support themes from the base system, then a custom interface that caused /usr/share/themes to be mounted into the sandbox might be sufficient. This would leak all installed themes to the confined app, but maybe that’s not so bad if we’re also telling them which theme the user prefers.

Here’s a sketch of what that could look like:

Update the core snap to include an empty /usr/share/themes directory.

Add a new themes interface to snapd that is provided by default on classic systems.

In the new themes interface, use the MountConnectedPlug method to add a mount entry mapping /usr/share/themes from the base system to the new mount name space.

This would also require that the themes on each supported Ubuntu version also support the versions of GTK that are used by the confined apps (which could be newer or older than that shipped by the distro release).

I’d say No since in my understanding all snaps should strive to have strict confinement and run on an all-snaps system. Not supporting theming in that use case would seem to make it less attractive for anyone to work towards those goals, unless you’re proposing an intermediary solution like the home interface.