This is a summary of some of the snapd/snapcraft issues that are important for to the Ubuntu Desktop team in order to provide the best possible snap experience. I’ll update this post as more things come up and things are fixed. If I’ve missed something important, please tell me
Snapped applications should use the desktop’s theme.
snapcraft-desktop-helpers cloud parts stage the standard Ubuntu theme into your package. That gives decent integration up until the point a user changes the theme.
Snaps should be able to access a theme that is (a) visually compatible with the user’s desktop and compatible with the toolkit version the application is using. The themes installed on the base system won’t necessarily meet these requirements, so it probably means we need snap packaged themes.
At a minimum, we want to support the commonly used themes, and ideally allow third parties to provide versions of their own themes for use with snaps. Zygmut suggested this might involve the use of not-yet-implemented “content snaps”.
Allow snapped applications to access system fonts
snapcraft-desktop-helpers cloud part ships the Ubuntu font with a snap, which is fine provided the font covers your spoken language. If you require another font to display readable text, you’re out of luck.
Making the system fonts available to strict confined apps might be the best way solve this. We don’t have the same compatibility concerns as for themes, since font formats are relatively static. Would we also need to make some of the fontconfig configuration visible too?
Status: core snap PR created. Still need to look at the snapd side.
Allow graphical installation/removal of snaps without a store account
From the command line, there is a low barrier to entry for people wanting to try a snap: if you’ve got
sudo access, you can start installing and removing snaps right away. This puts them on par with installing
.deb packages from the archive.
If the user is using
gnome-software instead though, they will need to create an Ubuntu One account and sign in before they can start installing or removing snaps. Ideally the user could prove their administator credentials in the same way they do for installing
The simplest solution would be to add polkit authorisation support, which is used for most other graphical administration tasks:
Status: Basic polkit support for
/v2/login API has landed in master. Expanding this to handle package install/removal is under review.
xdg-desktop-portal is a D-Bus service that grew out of the flatpak project as a way to give confined applications controlled access to various desktop services. This includes, but is not limited to:
- opening or saving user-selected files from outside the sandbox via trusted file pickers,
- opening URLs in the user’s web browser (similar to our custom
xdg-open in the core snap)
- printing documents
- accessing the user’s network proxy configuration
- Inhibiting the screen saver for things like media playback.
Modern versions of GTK have support for
xdg-desktop-portal baked in, and there is a QPA plugin to let Qt applications use it too. So I think it makes more sense to adopt this technology for use by snaps on the desktop rather than try to build an equivalent and try and get buy-in from the toolkit developers.
I put together a proof of concept for this here:
Getting this working properly will require some changes to the way
snap-confine works though: we most likely need to create separate mount namespaces for each user who tries to run the snapped application, and ensure that the mount namespace is destroyed at the termination of the desktop session. This has been discussed in the following thread:
Snapcraft should make it easier to build non-relocatable applications
Many applications embed their install prefix into configuration files or the executable itself. This should be relatively easy to support, since an app can assume it is available at
autotools plugin doesn’t make it easy to bake this prefix into an app. At first, it looked like the
install-via: prefix option would help but it ends up baking in the temporary install directory of the build system instead.
We probably want to instead do something like:
make install prefix=$SNAPCRAFT_PART_INSTALL
Let developers build snaps with the gnome-builder IDE
I made a first stab at implementing a Snapcraft plugin for
gnome-builder, but when trying to upstream it I was asked to make a few changes that are difficult to implement with vanilla snapcraft.
The primary request was to let
gnome-builder run the underlying build system itself, and build from the primary copy of the source. This is to allow (a) programmatic manipulation of the project (e.g. updating a target when a new source file is added), and (b) allow incremental recompilation when the user makes a change rather than starting the build from scratch.
I made a proposal about what I’d need from Snapcraft to implement this, but haven’t had a response so far:
Provide translated package summaries and descriptions
Currently package metadata is not translated, so package information appears in English no matter what the user’s native language is. If an app developer wants to make their package available to a global audience, they should be able to provide the summary and description in multiple languages.
Snapd should be able to access these translations (where ever they happen to end up being stored) and provide them to API users. @robert.ancell has made a first step of getting the
snapd-glib library to send an
Accept-Language HTTP request header, so when snapd gains support for translated metadata, it should work with
There is likely to be more tasks, but these are the primary ones that likely require some change to
snapd or Snapcraft.