It can lead to some changes in behaviour, so is something the developer would need to test. It is something that the developer needs to opt in to though. That automatically adds a number of best-practice features to the developer’s snap, and often means that rebuilding the snap with a new version of Snapcraft will improve the snap’s experience. The current solution is the Snapcraft extension system. Now, there can be problems, like incompatible themes, incompatible color schemes, etc, but this would remedy a lot of default issues. Snaps just need to be updated to use them, and we need the automatic theme installer in place.Ī solution could be to important user desktop settings into a common snap space that would be accessible to all of the snaps. I personally think the current setup of the theme content snaps is great. To that end, the broadest, most comprehensive solution would be to transparently match outside-of-snap visual elements to those inside the snap. Content snaps definitely do their job, but since they rely rebuilding/refactoring, we end up with significant divergence - fonts, dpi, scaling, theming, color scheme, etc - as a result of the snapd confinement.

Optionally, Snapd can also filter out binary-incompatible components that do not match the snap-contained environment (e.g.: themes compiled for a newer version compared to the core).īut this could be done without user interaction, and without rebuilding of snaps.

With layouts, these can be made to match what apps normally expect on the Linux host, e.g.: ~/.gtkrc-2.0, ~/.kde4, ~/.config, ~/.icons, and so forth.

Snapd exposes - automatically and transparently - contents under $SNAPDUSER - to every snap at runtime.

Snapd scans and takes desktop-specific content, like say /usr/share/themes and copies them into $SNAPDUSER.Snapd creates a per-user directory (let’s call it $SNAPDUSER).

I was thinking something slightly different:

Snapcraft spotify