Hello all,
We’ve just had a good call (and rather long, thanks to @zyga-snapd and @jamesh for taking the time) to synchronize on the status of the on going desktop support improvement and the plan for the upcoming weeks. I’ll summarize what we discussed below.
Let’s please keep this topic only to discuss the work organization. If you’d like to discuss any of the particular changes, please go to the respective topics linked from here.
Themes
The work on themes was parked for a while waiting on the improvements that are happening on the mount backend, which underpins improvements happening in the content interface and most importantly the upcoming layouts feature.
With these latter pieces landing, themes will be unblocked. The very first version of the feature will leverage a single snap containing a number of common themes which can be used as the default-provider in content interfaces in client applications. This is easy to do and will get us good looking applications in the short term.
Later we’ll then introduce improvements that will allow finding and installing snaps providing arbitrary themes that match the local environment needs. We have initial ideas here but the details still need to be designed.
User mounts
A number of desktop-related features require exposing per-user directories into the snap mount namespace. A preliminary patch is under review that implements that, with the caveat that the procedure is not following the standard practice we intend for snap mount namespace support in general. What we aim for is full dynamic mounts that can be added, removed, and updated on the fly with any application inside that snap running. What the patch implements instead is the creation of a namespace that inherits from the default snap namespace and adds the user mounts on top, and neither persists or ever updates that namespace again, but only discarding it when the application stops running.
We agreed to proceed with the preliminary implementation and land it after the usual review takes place, and then fix it in tree so that it conform to the usual namespace rules for snapd. We have worries about that process because in past cases it took a long time for us to come back and fix the problem as new priorities came up, but given the commitment to come back and fix it, we agreed that the partial feature is a reasonable path.
We also discussed how the proper implementation should look like, and the plan is to persist the user-bound namespace next to the base snap namespace, still preserving that two-layered approach as it simplifies addressing both the global and the user-specific namespaces for their maintenance. The user mounts will then be added, removed, and updated in the user-specific namespace using snap-update-ns as usual for every other mount namespace maintained by snapd. We’ll also need to support an additional internal flag to certain mounts that when enabled will force their removal when all user sessions are terminated, and re-establishment when the user logins in again. This ensures certain mounts that are inherently associated with the user session remain bound to the correct location.
Portals
The work on portals is under way and relies on the user mounts feature mentioned above to expose particular files selected by the user into the namespace of the application.
In addition to user mounts, the underlying portal infrastructure also needs to be patched to understand the idea of snaps as confined applications that can talk to that system under its terms. At the moment most of the system relies on hardcoded logic that only takes flatpaks into account, but on-going discussions with the upstream about changing that situation seem positive.
As an important requisite for that work, whatever final outcome we agree on and work towards needs to be supported in all Linux distributions. It’s unacceptable to have a solution that would make snaps only work in Ubuntu or any other particular distribution, unless that’s a temporary measure that will get sorted once their version of the portal tools get updated to the latest upstream release.
Wayland
We quickly discussed wayland support, but the high level agreement is that it should be easy to support it once the user mounts internal support is in place.
What’s next
Given the exposed above, we agreed to order the next few steps in the following way. This touches most critically the agenda of @jamesh who is directly working on those features, but also concerns the relevant review and design.
-
Get the current patch for user mounts merged and working.
-
Go back to themes and make sure they work end-to-end, with
a simple implementation that has all themes in the same snap and
leverage the default-provider mechanism to get installed. -
Go back to portals and make sure the required patches are in place
and upstreamed so that they work end-to-end. -
Make sure wayland works too.
-
Go back to refactor the user mount namespace support so that they
are persistent and snap-update-ns is used to dynamically add, remove,
and update namespaces on certain events such as once all sessions for
a user sessions are gone