Just a few other points to think about:
detecting the current theme:
For X apps, this is done via the xsettings protocol, which should work fine via the
For Wayland apps, GTK uses GSettings/dconf to detect the current theme. This can be accessed using the
gsettingsinterface, but that gives read/write access to all the users’ settings. Ideally this wouldn’t be necessary.
Some theme formats, like
gtk-2.0may require executable code, which will be running in the application’s security context. So if we do have some kind of extension point API, it might require assertions to allow a snap to provide an extension point.
Other theme formats like GTK 3 themes and icon themes should be safe though, so I imagine we could have automatic approval of most themes. Possibly in conjunction with some automated sanity checks to make sure the files being exported are of the expected type (e.g. CSS files for GTK themes, image files for icon themes, etc).
Ideally, developers shouldn’t need to include much boiler plate to support standard features. One possible way to do this would be to add
slots(and extension points?) sections to parts in the
snapcraft.yamlfile. Snapcraft would then copy these to the top level if there is nothing with the same name.
This way, the
desktop-gnome-platformcloud part could ship the boilerplate so all snaps using it pick it up.