Content interface - can the mountpoint be created dynamically? (needed for themes)

1

Hey there,

Does anybody know if it’s possible today to define/change the
content-interface target directory when the interface is being
connected? If that’s not possible yet, is it on the snappy team roadmap?

(The content interface doesn’t seem to
cover that topic)

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

  • the theme snap would have this declaration

slots:
ambiance:
interface: content
content: desktop-theme
read:

  • /usr/share/themes/Ambiance
  • the gtk-demo snap

plugs:
themes:
interface: content
target: $SNAP/share/themes/$THEME_NAME
default-provider: ubuntu-themes

The issue is that the target directory needs to be created dynamically
since it has to reflect the name of the theme mounted…

We also need to be able to do several desktop-theme mounts under
different directories (if the machine wants to make several themes
available to the users).

We do need to mount the different themes together because:

  • the snaps mounts are not specific to one user and different users on
    the same system might use the snap under different desktop environments
    or with different themes
  • GNOME allows to change themes dynamically by setting a gsettings key,
    that needs to keep working

Does anybody know how that could be made to work or maybe some idea of
alternative solution?

Cheers,

Sebastien Bacher

2 Likes
2

I guess there are a few questions to raise here:

  1. would we be okay with a solution that only works for classic?
  2. do we expect multiple snaps to provide themes simultaneously?
  3. if we’re only targeting classic, would it be acceptable to only support the themes installed on the base system?
  4. do we care about themes installed into the user’s home directory?
  5. 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:

  1. Update the core snap to include an empty /usr/share/themes directory.
  2. Add a new themes interface to snapd that is provided by default on classic systems.
  3. 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).

3

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.

4

I interpreted @jamesh comment on ‘classic’ to be ‘classic distro’, not ‘classic confinement’. ‘classic distro’ of course includes strict confinement.