Lets say that we have a
gtktheme snap containing the user’s selected theme exported via content interface, and a
gtkapp snap that plugs into it. Now lets add a second user to the system, who goes ahead and changes to a different theme. What now?
- Do we disconnect and reconnect the plugs on all installed apps each time someone logs in? (what about multi-seat when multiple users are logged in simultaneously?)
- Do we require all available themes to be packaged in a single snap? (how do theme authors get their theme added to this snap?)
The extension point idea effectively changes from a many-to-one connection strategy to many-to-many. So all snaps that are interested in GTK themes would see data from all installed snaps that provide GTK themes.
This could potentially be modelled as a many-to-one relationship plus a one-to-many one through an intermediate snap (e.g. the GNOME platform snap), with the help of some kind of “reverse content interface” where the plug snaps provide content to the slot snap, but that has its own problems:
- snaps have independent mount namespaces, so creating mounts within the GNOME platform snap won’t make content visible to other snaps that plug into it. We’d need some way to transmit information about the platform’s theme plugs to its app plugs in order to work out what to mount.
- it introduces dependencies between snap connections. Plugging a new theme into the platform snap would require refreshing the connections of all the app snaps.
At that point, it’s not clear it is worth trying to squash this into the existing constraints.