Experimental GNOME runtime

[Sebastien Bacher]

Hey there,

In the desktop team we have been working on providing a GNOME runtime
snap and got a first working version uploaded this week. If you are
interested to try it with your own snap-using-gtk3 or simply have a look
and give us some feedback it's a command away:

$ sudo snap install --edge gnome318-udt

(the udt stands for 'Ubuntu Desktop Team')

The snaps provides a 'gnome318-runtime' interface which you can connect
to using the content interface:
$ sudo snap connect <yoursnapname>:gnome318-runtime
gnome318-udt:gnome318-runtime

It should be relatively easy to use but you might enjoy some example to
copy from:
https://code.launchpad.net/~ubuntu-desktop/ghex/snap-share-content
https://code.launchpad.net/~ubuntu-desktop/gnome-calendar/snap-share-content

(ghex is simple, gnome-calendar shows how to bundle an extra deb)

That ghex snap once built take 1.5M (compared to 70M for the version not
using the content interface).

That's the summary but for those of you who likes a bit more details
like me add some (and reply to some questions you might have)


* The snapcraft.yaml used for the build can be found on
https://code.launchpad.net/~ubuntu-desktop/+junk/snap-gnome-udt

* The examples use a bunch of tricks

- The current snapcraft-desktop-helpers helper is being adapted to
handle the new location where the content is shared (we standardized on
'/gnome-runtime' so please use that if you plan to use the standard
launcher, your snap needs to include that empty directory so the content
can be mounted). We got changes in a branch with Didier but we
overlooked some details that I found out after he left for holidays.

To not get blocked on those changes to be land I pushed an hackish
helper to lp:~ubuntu-desktop/+junk/snap-launcher-hack which you can use
with the dump plugin, it creates the mountpoint directory for you and
bundles a version of 'desktop-launch' which is compatible with the new
runtime)

- the prefix is changed and a reorganize rule is used to workaround the
snappy relocation issues described in
https://launchpad.net/bugs/1583250. With that workaround you get
gettext/GNOME translations working (not in ghex though but it's due a
bug in the upstream build)

- there is a 'workaround' part which basically excludes libgtk and its
depends, that's to workaround snapcraft trying to help by copying in the
snap the libraries you need ... which is usually right but not what you
want with content sharing.

- the calendar snap uses libraries that are not in the runtime (like eds
or libical), those get automatically copied over by snapcraft but we
also add evolution-data-server-common to the bundle because it provides
a gsettings schemas needed by the eds libraries

* The stack is built from xenial (so GNOME 3.18) using the archive debs,
it gives us a well tested version and a known environment we are
building from. It also means the toolchain used for the build is the
same as the ubuntu-core one and that you can build&test your snaps on a
xenial desktop installation.

* The current version only includes core libraries and some desktop
integration components (icons, mimetypes definition, theme, etc). We
might revisit the content and add more things later but we didn't want
to include too much since we easily add libraries but we can't remove
existing ones since they might be used by others.

It's easy to bundle an extra lib with your snap if you need one though.

* We plan to provide newer GNOME stacks as well

* It seems that snaps can't auto-connect to a shared interface from
another providers at the moment so there is manually work required from
the user to get things working, unsure what's the plan from the snappy
team there.


Happy testing and let us know if you have any comment by replying to
that email of by contacting the desktop team mailing list or IRC channel
(might be a bit quiet during holidays).

Cheers,

Sebastien Bacher