Ubuntu Desktop Team Priorities

[jamesh]

It’s a new year, so it’s probably time for an update on this list. These are issues that I’ve either been working on recently, will be working on in the near future, or am aware of. If

• Snapped applications should match the desktop’s theme
  The plan is still to package themes as snaps, as the themes on the host system are not guaranteed to be compatible with the libraries available in the sandbox. We came up with a basic sketch for how this would work at the Hague sprint (extending the content interface to allow a snap to mount content from multiple sources at once), but it still needs to be implemented.

  • Use the system gtk theme

• Support xdg-desktop-portal/xdg-document-portal
  This is desirable because it increases the capabilities of desktop applications that don’t plug the home interface, among other things: the application can be given the ability to open or save files in any location the user can access, without being given access to any locations the user hasn’t explicitly granted access to.

  One component of this work was to add support for “user mounts” – that is bind mounts in the sandbox mount namespace that are specific to the current user. The main use case for this was xdg-document-portal, which relies on a specific bind mount to make files available to the container securely. There is a pull request for this feature, but it is as yet unmerged.

  I also started the process of trying to upstream support for detecting snaps in xdg-desktop-portal. They are receptive to adding support, but would prefer to handle it via an in-development “app container socket” feature for dbus-daemon. A discussion was started around supporting this in the way we set up dbus access for confined apps, but it will require implementation work.

  • Can interfaces define per-user bind mounts?
  • https://github.com/snapcore/snapd/pull/3963
  • Interacting with dbus-daemon's "app container" feature
  • https://github.com/flatpak/xdg-desktop-portal/pull/136
  • https://bugs.freedesktop.org/show_bug.cgi?id=100344

• Speed up first launch of desktop apps
  Snaps using the snapcraft-desktop-helpers desktop-launch script had noticeable delays on first start. I identified some of the more costly actions and looked at solutions that allow some of that work to be moved from first run to package build time.

  Parts of that work have landed in snapcraft-desktop-helpers, and changes to the GNOME platform snap will let some applications take advantage of the speed ups right away. However, we don’t have a good solution for apps that bundle their own GTK or Qt. This will probably need the Snapcraft extended scriptlets feature to be implemented and merged.

  • Improving first run performance of desktop app snaps
  • Feature request: let a part modify files ater staging

• Various gnome-software tasks

  There are a number of improvements in the works for gnome-software’s snap support, some of which require corresponding snapd changes. I’ll break this out into separate issues soon.