![]() 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: ![]()
0 Comments
Leave a Reply. |