Canonical Voices

David Callé

If it hasn't already, snapd 2.0.10 should be making its way to your 16.04 systems. Here is what’s new!

The 2.0.10 release contains a number of improvements and fixes over the 2.0.9 release that was available before. The highlights:


Channels (stable, candidate, beta, edge) usage has been streamlined on the client.

As a shorthand to --channel=<channel>, you can now use --<channel> with the refresh and install commands.

For example:



New interfaces have landed with this release, giving you more freedom to interact with the OS, while keeping your app into the bounds of the existing confinement. This allows, for example, for improvements in the VLC snap’s user experience.

Screenshot from 2016-07-11 13-35-02.png

mpris (new)

  • Allows snaps such as music players to connect to D-Bus as an MPRIS server.
  • You can see an usage example in the VLC snapcraft.yaml.

camera (new)

optical-drive (new)

  • Grants read access to optical drives.


  • Allow gvfs shares in home.


  • Snaps can be launched under KDE Neon

  • SNAP_COMMON and SNAP_USER_COMMON are paths to unversioned data directories

  • Better handling of removed `snap try` directories

  • Fixes towards running snapd inside LXC

  • `snap change <taskid>` shows task progress

  • Auto-connect the home interface only if running on classic

The changelog is available here and the full details can be found here:

Let us know what you think!

We’d like to hear your feedback about snapd and snap technologies. Is there an interface you would need for your app to be working better? Can we do better with integrating with a particular distro? Here’s how we can talk:

Read more
Didier Roche


Integrating desktop applications with snaps has been a little bit challenging in terms of getting them looking and behaving as part of the system. This means following general desktop theming, having global application menu integration, getting the icon caches, getting configuration keys and such. Also, the technologies and toolkits like GTK, Qt, demand a little bit of expertise on that front.

That's the reason why we saw flourishing some desktop helpers like gtkconf or qtconf as cloud snapcraft parts for this. However, they were sharing little code and some part of the integration was working for one flavor and not the other flavor and vice-versa.

New desktop launchers to the rescue!

This is the reason why we are announcing new destkop launchers! The goal was to streamline the experience and ensuring that all following user visible features are working, independent of the toolkit or technology you are using:

  • Bind with current desktop theme if shipped by default (GTK & Qt)
  • Icons theme available for decoding (with the right decoders automatically shipped)
  • Application menu integration (in Unity)
  • Icon cache and images generated on first launch (no more need to ship pre-compile GSettings and Gio caching modules) after a new upgrade
  • Keep previous xdg-based data, even after upgrade
  • GSettings keys available for reading (not only writing)
  • Most of the code is shared between the launchers, so any fix in one will benefit others, and we assemble them at build time.
  • Avoid erratic behavior like cd $SNAP that some launchers were doing and not others (we don't change the current working directory anymore)

Ristretto before applying desktop/gtk3     Ristretto with desktop/gtk3

Those new cloud parts also ship with default package set configuration to ensure all features are enabled, this is overridable as well, as explained by Sergio in his blog post.

Qt-based applications also show those drastic improvements. Note that the appmenu fix for Qt applications will only work starting with snapd 2.0.10.

SMPlayer before using desktop/qt5   SMPlayer using desktop/qt5

Definition and usage

We currently have 5 launchers, depending on the technology you want to support: gtk2, gtk3, qt4, qt5 and glib-only for a lightweight, non graphical app, but needing basic integration like GSettings and MIME types.

Those are grouped under the "desktop" namespace from the snapcraft cloud part functionality, with extensive help on how to use them:

$ snapcraft define desktop/qt5
Maintainer: 'Snapcraft community <>'
Description:  |
  Helpers for gtk2, gtk3, qt4 and qt5 or glib minimal launchers.
  It brings the necessary code and exports for binding and using those
  desktop technologies in a relocatable fashion, enabling binding with
  global desktop theme, icon theme, image caching, fonts, mimetype handlers
  application global menu and gsettings integration.
  It also brings basics ubuntu dependency packages.
    1. add "after: [desktop/<technology>]" to your launcher:
       - gtk2, gtk3, qt4 and qt5 corresponds to their respective toolkit
         main dependencies and default choices.
       - glib-only enables to compile mime types and gsettings infos. If you
         added your own graphical drivers, it will link them as well.
    2. prepend your command with "desktop-launch", like:
       commands: "desktop-launch foo" if foo is in $PATH. You can as well
       specify: "desktop-launch $SNAP/foo".
    3. add needed plugs to your application:
       - for graphical application:
         plugs: [x11 (or unity7 for appmenu integration)]. Think about adding
         opengl if you need hw acceleration.
       - if your application needs access to sound:
         plugs: [pulseaudio]
       - accessing to user's home directory:
         plugs: [home]
       - read/write to gsettings:
         plugs: [gsettings, home]
         (note that the home plug is needed to read new value)'
  - qtbase5-dev
  - dpkg-dev
  - FLAVOR=qt5
  plugin: make
  source-subdir: qt
  - libxkbcommon0
  - ttf-ubuntu-font-family
  - dmz-cursor-theme
  - light-themes
  - shared-mime-info
  - libqt5gui5
  - libgdk-pixbuf2.0-0
  - libqt5svg5
  - appmenu-qt5

(Note that the descriptions are for now common to any namespaces launchers)

Migrating from gtkconf/qt4conf/qt5conf

As part of this journey, I wanted to see this applied in the real world and migrated all snappy playpen examples to this new launchers. I was delighted to see that some of the goals, like having smaller snapcraft.yaml was a success. Also, broken examples are now fully integrated to the desktop (see some of the pictures above).

Migrating is the existing gtkconf/qt4conf/qt5conf (we plan to deprecate them after a while) is a 2 minutes job:

  1. Replace: after: [<xxx>conf] with after: [desktop/<xxx>] where <xxx> is the targeted toolkit.
  2. Change command: gtk-launch (or qt-launch) foo with commands: desktop-launch foo. For simplicity, all launchers are now called "desktop-launch". Note that foo needs to be in $PATH for your snap, if it's not, replace it to $SNAP/foo.
  3. You can (not mandatory) clean up any build-packages or stages-packages that are shipped and expose in the desktop launcher definition.

By following those simple steps, you can get from an unthemed, no matching icons and no appmenu VLC to a fully integrated one!

Happy snap desktop integration! :)

Read more
David Planella

Shaping up universal snaps

Following the announcement of snaps being supported across a range of key Linux distributions, the development teams working on snaps and Snapcraft are making universal snaps one of the main topics of their next sprint in Heidelberg, Germany, from 18-22 July.

Snappy sprints are face-to-face events where multiple teams working on snap technologies, including Ubuntu founder Mark Shuttleworth, get together to plan, design and develop their next release and longer term roadmap. After the initial positive reception amongst initial adopters, tech media and wider open source community, continuous improvement of the snap user and developer experience is a major focus.

A number of upstreams, contributors and developers of leading open source projects such as DebianElementary OS, Fedora, KDE, Kubuntu, MATE or VLC have already confirmed participation at the sprint to collaborate on better distro-agnostic snap support.

At this point, we'd like to extend this invitation to contributors of other projects to influence the roadmap and work together on shaping up the universal snaps story. If you are interested in participating, we have a limited amount of seats available at the sprint, subject to review and confirmation. Should they need it, sponsorship for travel and accommodation will be available for a set of contributors of upstreams, distros or desktop projects who are willing to actively work towards this goal.

If the answer is yes, feel free to apply for participation and sponsorship to the Heidelberg snappy sprint

Please note that a sprint is not a tech conference: it is a set of focused working and planning sessions where the snappy Engineering team execute work items and plan the next iteration of snapd and Snapcraft. Attendees will be expected to actively participate in discussions and decision making and be willing to take work items where appropriate.

Also do note that while all contributions are valuable, we have a limited capacity to sponsor participants and we cannot support everyone. As such, sponsorship will be subject to review and final confirmation. Once the requests are in, we will review all of the applicants and contact you as soon as possible to let you know if your request for sponsorship has been approved.

It will be a great chance to build together app distribution across platforms and we’ll be looking forward to working with you!

Read more
David Callé

Snapcraft 2.12 is here and is making its way to your 16.04 machines today.

This release takes Snapcraft to a whole new level. For example, instead of defining your own project parts, you can now use and share them from a common, open, repository. This feature was already available in previous versions, but is now much more visible, making this repo searchable and locally cached.

Without further ado, here is a tour of what’s new in this release.


2.12 introduces ‘snapcraft update’, ‘search’ and ‘define’, which bring more visibility to the Snapcraft parts ecosystem. Parts are pieces of code for your app, that can also help you bundle libraries, set up environment variables and other tedious tasks app developers are familiar with.

They are literally parts you aggregate and assemble to create a functional app. The benefits of using a common tool is that these parts can be shared amongst developers. Here is how you can access this repository.

  • snapcraft update : refresh the list of remote parts
  • snapcraft search : list and search remote parts
  • snapcraft define : display information and content about a remote part


To get a sense of how these commands are used, have a look at the above example, then you can dive into details and what we mean by “ecosystem of parts”.

Snap name registration

Another command you will find useful is the new ‘register’ one. Registering a snap name is reserving the name on the store.

  • snapcraft register


As a vendor or upstream, you can secure snap names when you are the publisher of what most users expect to see under this name.

Of course, this process can be reverted and disputed. Here is what the store workflow looks like when I try to register an already registered name:


On the name registration page of the store, I’m going to try to register ‘my-cool-app’, which already exists.


I’m informed that the name has already been registered, but I can dispute this or use another name.


I can now start a dispute process to retrieve ownership of the snap name.

Plugins and sources

Two new plugins have been added for parts building: qmake and gulp.


The qmake plugin has been requested since the advent of the project, and we have seen many custom versions to fill this gap. Here is what the default qmake plugin allows you to do:

  • Pass a list of options to qmake
  • Specify a Qt version
  • Declare list of .pro files to pass to the qmake invocation


The hugely popular nodejs builder is now a first class citizen in Snapcraft. It inherits from the existing nodejs plugin and allows you to:

  • Declare a list of gulp tasks
  • Request a specific nodejs version


SVN is still a major version control system and thanks to Simon Quigley from the Lubuntu project, you can now use svn: URIs in the source field of your plugins.


Many other fixes made their way into the release, with two highlights:

  • You can now use hidden .snapcraft.yaml files
  • snapcraft cleanbuild’ now creates ephemeral LXC containers and won’t clutter your drive anymore

The full changelog for this milestone is available here and the list of bugs in sight for 2.13 can be found here. Note that this list will probably change until the next release, but if you have a Snapcraft itch to scratch, it’s a good list to pick your first contribution from.

Install Snapcraft

On Ubuntu

Simply open up a terminal with Ctrl+Alt+t and run these commands to install Snapcraft from the Ubuntu archives on Ubuntu 16.04 LTS

sudo apt update
sudo apt install snapcraft

On other platforms

Get the Snapcraft source code ›

Get snapping!

There is a thriving community of developers who can give you a hand getting started or unblock you when creating your snap. You can participate and get help in multiple ways:

Read more
David Barth

Cordova Ubuntu Update

A few weeks ago we participated to Phonegap Day EU 2016

A few weeks ago we participated to Phonegap Day EU 2016. It was a great opportunity to meet with the Cordova development team and app developers gathered for this occasion.

We demo'ed the latest Ubuntu 16.04 LTS release, running on a brand new BQ M10 tablet in convergence mode. It was really interesting to discuss with app developers. Creating responsive user interfaces is already a common topic for web developers, and Cordova developers by extension. 

On the second day, we hosted a workshop on developing Ubuntu applications with Cordova and popular frameworks like Ionic. Alexandre Abreu also showed his new cordova-plugin-ble-central for Ubuntu. This one lets you connect to an IoT device, like one of those new RPI boards, directly to an Ubuntu app using the Bluetooth Low Energy stack. Snappy, Ubuntu and Cordova all working together !

Last but not least, we started the release process for cordova-ubuntu 4.3.4. This is the latest stable update to the Ubuntu platform support code for Cordova apps. It's coming along with a set of documentation updates available here and on the upstream cordova doc site

We've made a quick video to summarize this and walk you through the first steps of creating your own Ubuntu app using Cordova. You can now watch it at:

Let us know about your ideas : we're eager to see what you can do with the new release and plugins.

Read more
Benjamin Zeller

New Ubuntu SDK Beta Version

A few days ago we have released the first Beta of the Ubuntu SDK IDE using the LXD container solution to build and execute applications. 

A few days ago we have released the first Beta of the Ubuntu SDK IDE using the LXD container solution to build and execute applications.

The first reports were positive, however one big problem was discovered pretty quickly:

Applications would not start on machines using the proprietary Nvidia drivers. Reason for this is that indirect GLX is not allowed by default when using those. The applications need to have access to:

  1. The glx libraries for the currently used driver
  2. The DRI and Nvidia device files

Luckily the snappy team already tackled a similar problem, so thanks to Michael Vogt (a.k.a mvo) we had a first idea how to solve it by reusing the Nvidia binaries and device files from the host by mounting them into the container.

However it is a bit more complicated in our case, because once we have the devices and directories mounted into the containers they will stay there permanently. This is a problem because the Nvidia binary directory has a version numbering, e.g. /usr/lib/nvidia-315, which changes with the currently loaded module and would stop the container from booting after the driver was changed and the old directory on the host is gone, or the container would use the wrong nvidia dir if it was not removed from the host.

The situation gets worse with optimus graphics cards were the user can switch between a integrated and dedicated graphics chip, which means device files in /dev can come and go between reboots.

Our solution to the problem is to check the integrity of the containers on every start of the Ubuntu SDK IDE and if problems are detected, the user is informed and asked for the root password to run automatic fixes. Those checks and fixes are implemented in the “usdk-target” tool and can be used from the CLI as well.

As a bonus this work will enable direct rendering for other graphics chips as well, however since we do not have access to all possible chips there might be still special cases that we could not catch.

So please report all problems to us on one of those channels:

We have released the new tool into the Tools-development PPA where the first beta was released too. However existing container might not be completely fixed automatically. They are better be recreated or manually fixed. To manually fix an existing container use the maintain mode from the options menu and add the current user into the “video” group.

To get the new version of the IDE please update the installed Ubuntu SDK IDE package:

$ sudo apt-get update && sudo apt-get install ubuntu-sdk-ide ubuntu-sdk-tools

Read more
David Callé

As of today and part of our weekly release cadence, a new snapd is making its way to your 16.04 systems. Here is what’s new!

Command line

  • snap interfaces can now give you a list of all snaps connected to a specific interface:
  • Introduction of snap run <app.command>, which will provide a clean and simple way to run commands and hooks for any installed revision of a snap. As of writing this post, to try it, you need to wait for a newer core snap to be promoted to the stable channel, or alternatively, switch to the beta channel with snap refresh --channel=beta ubuntu-core


  • Enable full confinement on Elementary 0.4 (Loki)
  • If a distribution doesn’t support full confinement through Apparmor and seccomp, snaps are installed in devmode by default.


  • Installing the core snap will now request a restart
  • Rest API: added support to send apps per snap, to allow finer-grained control of snaps from the Software center.

Have a look at the full changelog for more details.

What’s next?

Here are some of the fixes already lined up for the next snapd release:

  • New interfaces to enable more system access for confined snaps, such as “camera”, “optical-drive” and “mpris”. This will give a lot more latitude for media players (control through the mpris dbus interface, playing DVDs, etc.) and communication apps. You can try them now by building snapd from source.
  • Better handling of snaps on nvidia graphics
  • And much more to come, watch the new Snapcraft social channels ( twitter, google+, facebook) for updates!

Read more
Daniel Holbach

Week 3 of the Snappy Playpen

Next week we're going into the third week of the Snappy Playpen. An initiative to snap together, learn from each other, document best practices and get together as a team.

Get started with Snappy

The Snappy Playpen is hosted in github and we meet in both #snappy on Freenode and our gitter channel. We are hanging out there most of the time, but next week on Tuesday, 21st June we will get all experts in one room and together we will make a push to get both

snapped. Obviously you can bring whatever own app you are interested in. Particularly if you are an upstream of a project, we're keen to help you get started.

Snaps are a beautiful and simple way to get your app out to users, so let's make this happen together.

If you are curious and want to take a first look, go to and we'll take care of the questions together.

  • WHAT: Snappy playpen sprint
  • WHEN: Tuesday, 21st June 2016 all day
  • WHERE: Join us on gitter or IRC

Read more
liam zheng

经过一段漫长的开发过程,我们很高兴地宣布,Ubuntu SDK IDE 的下一个版本从今天起进入 Beta 测试阶段。新版本包含全新的构建器 (Builder) 和运行时后端,最终消除了 SDK IDE 目前存在的最大问题。

Ubuntu SDK IDE 的下一个迭代

简单来说︰LXD 来了

经过一段漫长的开发过程,我们很高兴地宣布,Ubuntu SDK IDE 的下一个版本从今天起进入 Beta 测试阶段。新版本包含全新的构建器 (Builder) 和运行时后端,最终消除了 SDK IDE 目前存在的最大问题。

之前已经有传闻说基于 LXD 的新构建器将会取代基于 schroot 的构建器。没错,这些传闻都是真的。在几位值得信赖的测试人员对概念验证版本进行了一段时间的内部测试后,我们认为向更多人展示新版本 IDE 的时机已经到来。

下面,在直接介绍新软件包前,我们先来回顾一下不得不放弃 schroot 构建器的一些原因:

最大的问题无疑在于安装 SDK 后立即创建新的 chroot。从实时档案文件启动引导 (Bootstrapping) 完整的 Ubuntu 根文件系统非常缓慢,而且容易出错。每当档案文件或 Overlay PPA 存在打包问题时,就无法创建新的构建目标。这基本上导致 SDK 在打包问题修复前将一直不可用。LXD 已经解决了这个问题。新容器以现成可用的压缩映像文件形式下载,下载速度比以往快得多,而且得到的容器肯定可用,因为容器在发布前已经过我们的测试,而不是像 Overlay PPA 那样不断改变。映像下载完毕后将被缓存,而从缓存启动一个新容器只需要几秒钟!

第二个要强调的问题是,我们需要在桌面本地执行应用程序,但仍支持目前官方支持的所有 Ubuntu 版本。这意味着必须解决不同 Qt 和 UITK 版本的问题。我们曾经尝试过通过提供单独的 Qt+UITK 软件包来解决这个问题。但事实证明,这种方法需要破解和重构太多的软件包,因此是不可行的。而且,这不仅仅是构建时的问题,还是一个运行时的问题。那么如何既能在桌面上运行应用,使用最新、最流行的组件,同时又能保持 LTS 兼容性呢?

答案其实很简单:使用容器作为运行时目标,并在主机的 X 服务器上显示 UI。

此外还有一些问题,例如整体速度缓慢、挂载点泄漏(每个曾经因 schroot 而设置了数百个挂载的人都能明白我的意思)以及 ecryptfs 的问题等。

现在说够了过去,我们来聊聊将来,看看新版本有了哪些变化。在开始前需要指出的是,我们已经停止了对默认桌面套件的支持。默认已不再支持在主机上构建和运行应用。除了 qmake 和 cmake 插件自动创建的配置以外,SDK IDE 不会创建其他桌面运行配置。当然,我们还是有办法在主机上构建和运用应用的,但是需要手动创建运行配置。今后,我们需要创建一个与主机架构一致的容器来执行应用程序。这意味着,在主机系统上,几乎不需要使用额外的软件包作为依赖项。

IDE 将不再使用任何现有的基于 schroot 的构建器。click chroot 仍然留在主机上,但是将与 Ubuntu SDK IDE 分离。


做法很简单,我们只需添加 SDK 发行版和适用于 Ubuntu SDK 工具的 Tools Development PPA:

sudo add-apt-repository ppa:ubuntu-sdk-team/tools-development

sudo apt update && sudo apt install ubuntu-sdk-ide

完成上面的操作后,IDE 现在完全可用。它会按照过去使用 click chroot 时相同的方式来发现容器。从各个方面看,开发者的体验并不会有太大变化。需要注意的是,目前我们还在 Beta 测试阶段,因此容器映像或 IDE 本身很有可能存在一些 Bug。请直接在 IRC 上或通过邮件列表向我们报告 Bug,更好的方式是通过 launchpad 中的官方 ubuntu-sdk-ide 项目来报告 Bug:


lxd 组成员资格

通常,LXD 安装进程会配置必要的组成员资格。但如果该进程未配置成员资格,我们就需要确保当前用户属于 lxd 组。请发出以下命令:

sudo useradd -G lxd `whoami`


重置 QtCreator 设置

有时,在不同版本间来回切换时,QtCreator(Ubuntu SDK IDE 的 Qt 应用程序)的设置会发生损坏。当发现已损坏或无法使用的套件、配置上可能有误的设备或者任何不寻常的问题时,按下 Qtcreator 上的重置按钮可能会有帮助。注意,这是一种相当激进的修复方法。操作上很简单,只需执行下面这条命令即可:

$ rm ~/.config/QtProject/qtcreator ~/.config/QtProject/QtC*

清理旧的 click chroot

前面提到,旧的 schroot 已与 SDK IDE 分离,但是仍留在文件系统中。使用以下命令可清理 click chroot:

$ sudo click chroot -a armhf -f ubuntu-sdk-15.04 destroy

$ sudo click chroot -a i386 -f ubuntu-sdk-15.04 destroy

这两个命令将释放大约 1.4GB 的磁盘空间。click chroot 位于 /var/lib/schroot/chroots 下。最好检查一下该文件夹是否为空,并且没有挂载任何内容。

$ mount|grep schroot

NVIDIA 显卡驱动程序


在使用 NVIDIA 显卡驱动程序的主机上,无法从 LXD 容器本地部署应用。如果主机具有双图形处理器,一种变通的方法是使用另一个图形处理器。


$ sudo lshw -class display

如果列表显示除 NVIDIA 以外的其他条目,则激活另一个显卡。prime-select 工具是一个简单易用的工具。

$ sudo prime-select intel

注意,你的系统上可能未安装这个工具,而且它不能与 bumblebee 一起使用。如果主机已安装 bumblebee 且缺少 prime-select 工具:

$ sudo apt-get remove bumblebee

$ sudo apt-get install nvidia-prime

如果主机除 NVIDIA 以外没有其他显卡,可以尝试 Nouveau 驱动程序,该驱动程序也许能用。不管怎样,这是一个非常严重的已知问题,我们目前正在着手解决。

启动新的 IDE

首先备份一些设置,以防在极少数情况下我们需要恢复回当前的 IDE。

$ tar zcvf ~/Qtproject.tar.gz ~/.config/QtProject

然后,在 Dash 中找到 Ubuntu SDK IDE 并启动它。

Ubuntu SDK IDE 首先会检查环境是否已正确设置。除非你是 LXC/LXD 超级用户,否则安全的做法是选择此对话框中的“Yes(是)”。

如果 Ubuntu SDK 是第一次启动,会打开一个欢迎向导帮助你设置套件和设备。


按下“Create new Kit(创建新套件)”按钮,查看目标创建对话框。

在这一步中,可以在 3 种类型的目标间进行选择︰

  • Build to run on the desktop(构建以便在桌面上运行)- 筛选出所有与桌面兼容的映像
  • Build to run on device or emulator(构建以便在设备或模拟器上运行)- 筛选出所有可用于设备的映像
  • Show all available images(显示所有可用的映像)- 显示所有可用映像

我们选择“Show all available images”,查看所有现有映像的概览。

下一步,选择首选的目标架构。Ubuntu 手机和平板电脑是 armhf,主机 PC 是 i386 或 amd64。因此,要创建适用于手机的 click 包,需要 armhf 目标;要在桌面上测试应用程序,需要原生的 amd64 或 i386 目标。


创建 LXD 容器需要系统管理员权限,所以下面我们需要验证自己的身份。

输入正确的密码后,LXD 映像下载将开始。

下载需要些时间,具体取决于网络的带宽。每个映像大约为 400MB。在向导下载和配置 LXD 映像期间,我们刚好有足够时间来看一篇简短的博客文章,了解一下到底什么是套件:你想了解却又羞于发问的关于套件的一切 。毫不夸张地说,花时间阅读这篇博客文章并了解开发套件是什么,是最佳的选择。


向导的下一页将帮助你设置目标设备。在我们的例子中,我们已经有了一个 BQ (krillin) 手机和一个来自 rc-proposed 通道的模拟器。

在这个阶段,IDE 将自动发现 LXD 容器,并提示我们可以更新它。


完成该向导后,IDE 将打开。



Read more
David Callé

Yesterday, the snapcore team released a new version of snapd for Ubuntu 16.04. Snapd is the system service that enables developers and users to interact with snaps.

Features in 2.0.8

  • snap try. This command mounts any folder containing an unpackaged snap as an editable installed snap, making testing and iterating on snaps much faster. For example, if you are using snapcraft, you can run snap try prime/ in your working dir to mount prime/ as a installed snap and edit it while the snap is mounted.
  • Use os-release instead of lsb-release for cross-distro use
  • Add support for an environment map inside snap.yaml, although the matching snapcraft syntax has not landed yet.


New interfaces have been added with this release, giving more control to the way your snaps interact and exchange with the underlying OS (gsettings, pulseaudio, etc.). Their names are self explanatory, but for more details, you can have a look at the implementation. Note that some of these interfaces are “reserved” and will trigger a manual review in the store. Here is a summary of all changes:

  • Changes in the ‘unity7’ interface:
  • add DBUSMenu, Freedesktop and KDE notifications
  • allow AppMenu and launcher API
  • add fcitx and mozc input methods
  • add com.canonical.UrlLauncher.XdgOpen
  • Introducing the following interfaces:
  • network-manager’: allows operating as the NetworkManager service
  • cups-control’: allows access to cups control socket
  • location-control’ and ‘location-observe’: allow operating as the location service
  • pulseaudio’: allows access to audio (/etc/pulse and related paths)
  • gsettings’: allows access to global gsettings of the user's session
  • Autoconnect the ‘home’ interface
  • firewall-control’ can access the xtables lock file
  • Add socketcall() to the ‘network’ and ’network-bind’ interfaces
  • Allow using sysctl and scmp_sys_resolver for parsing kernel logs
  • Allow access to new ibus abstract socket path
  • Documentation updates

Command line

  • Implement `snap refresh --list` and `snap refresh` to view and manually apply available updates
  • Have 'snap list' display an helper message when no snaps are installed

The full changelog for this release is here. Note that the previous snapd update in 16.04  was 2.0.5, so this changelog extends from 2.0.6 to 2.0.8.

What’s next?

Here are some highlights from the list of features and fixes lined up for the next snapd release in 16.04:

  • Add new `snap run` command with hook support
  • Create SNAP_USER_DATA and common dirs in `snap run`
  • Have the installation of the core snap request a restart (on classic)
  • Install snaps in devmode on distributions without complete apparmor and seccomp support
  • Interfaces: miscellaneous policy updates for chromium, x86, opengl, etc.
  • Enable full confinement on Elementary 0.4 (Loki)

Read more
Benjamin Zeller

or: here comes LXD

The next iteration of the Ubuntu SDK IDE

or: here comes LXD

After a long development process we are pleased to announce that the next version of the Ubuntu SDK IDE will go into beta testing phase as of today and it comes packed with a completely new builder and runtime backend to finally get rid of the biggest issues the SDK IDE has today.

Some people already heard rumours about new LXD based builders that should replace the schroot based ones. Well, the rumours are true and after some time of internal testing of our proof of concept version with just a few trusted testers we think it is time to show the new IDE to a bigger audience.

Now, before jumping right on the new packages let’s revisit some of the reasons why we had to move away from the schroot based builders:

The biggest issue is for sure the creation of new chroots right after installing the SDK. Bootstrapping a full Ubuntu root file system from live archives is very slow and error prone. Whenever there is a packaging issue in the archives or overlay PPA it is not possible to create new build targets. Which basically makes the SDK unusable until the packaging issues are fixes. LXD already has solved that problem, new containers are downloaded as compressed and ready-to-go image files, downloading is much faster and the resulting container will work for sure since it was tested by us before releasing it as opposed to the continuously changing Overlay PPA. Once an image has been downloaded it is cached, and spinning up a new container from the cache is a matter of seconds!

The second issue I want to highlight is our requirement to execute the applications locally on the desktop, but still supporting all Ubuntu versions that are currently officially supported. Which means we had to deal with a list of different Qt and UITK versions. We tried to solve that problem by providing a separate Qt+UITK package but it turned out we’d have to hack and rebuild so many packages to make that work that it was just not feasible. And this is not only a build time problem, but also a runtime problem. How should we continue to make it possible to run apps on the Desktop, using the hottest and newest components while maintaining LTS compatibility?

The answer was actually very simple: Use the containers as runtime targets and show the UI on the host’s X server.

There were a few more issues, like overall slowness and leaking mount points (everyone who ever had hundreds of mounts because of schroot, knows what I’m talking about), issues with ecryptfs and more.

Now, enough with the past, let’s look into the future and what has changed. It is good to know before starting that we have dropped support for the default Desktop Kit. Building and running on the Host is not supported by default anymore. The SDK IDE will not create other desktop run configurations than what automatically created by the qmake and cmake plugins. It is of course still possible to build and run on the host, but the run configuration needs to be created manually. Instead from now on it’s required to create a container that matches the host architecture where the application is executed in. It means that on the host system almost no additional packages are required as dependencies. 

All existing schroot based builders will not be used by the IDE anymore. The click chroots will remain on the host but will be decoupled from the Ubuntu SDK IDE.

Get started

Its simple, all that needs to be done is to add the SDK Release and the Tools Development PPA for the Ubuntu SDK tools:

sudo add-apt-repository ppa:ubuntu-sdk-team/tools-development

sudo apt update && sudo apt install ubuntu-sdk-ide


And we are done, the IDE is now be fully usable. It will discover the containers just as it used to do with the click chroots. From all aspects, the developer experience will not change much. Please keep in mind we are still beta testing so there will be most likely some bugs, either with the container images or with the IDE itself. Please report them to us either directly on IRC or via mailing list, or even better on the official ubuntu-sdk-ide project in launchpad:

Known issues and troubleshooting

The lxd group membership

Normally the LXD install process takes care of configuring the necessary group membership. But if it does not then we have to make sure the current user is part of the lxd group issue this command:

sudo useradd -G lxd `whoami`

After that please relogin to make the new group known to the login session.

Reset QtCreator settings

Sometimes the settings of QtCreator (the Qt application of the Ubuntu SDK IDE) break when switching back and forth between different version. When you see broken or ghost Kits, or possible misconfigured devices, or in general anything what is weird it is possible that pushing  the reset button on Qtcreator helps. Note, that it is a rather radical fix. It can be easily done with a single command:

$ rm ~/.config/QtProject/qtcreator ~/.config/QtProject/QtC*

Clean up old click chroots

As mentioned before the old schroots are detached from the SDK IDE, but they remain on the file system. With the following commands it is possible to clean up the click chroots:

$ sudo click chroot -a armhf -f ubuntu-sdk-15.04 destroy

$ sudo click chroot -a i386 -f ubuntu-sdk-15.04 destroy

These commands will free about 1.4GB disk space. The click chroots live under the /var/lib/schroot/chroots/ It is a good idea to check if that folder is empty and nothing is mounted there

$ mount|grep schroot

NVIDIA video driver

Deploying apps locally from the LXD container i snot possible on hosts using NVIDIA graphics driver. If the host has dual graphic processor then one workaround is to use the other one.

Check if you have a backup graphics card

$ sudo lshw -class display

If that list shows other entries than the NVIDIA the activate the other video card. The prime select tool is a simple and easy tool to use.

$ sudo prime-select intel

Note that this tool might not be installed on your system and it does not work together with bumblebee. In case the host has bumblebee installed and missing the prime-select tool

$ sudo apt-get remove bumblebee

$ sudo apt-get install nvidia-prime

If the host has no other video card then the NVIDIA it is possible to use the Nouveau driver what might work. Anywhow, this is a known and very sever issue what we are working on.

Let start the new IDE

But first back up  some settings for the very unlikely case that we want to move back to the present IDE

$ tar zcvf ~/Qtproject.tar.gz ~/.config/QtProject

Then find the Ubuntu SDK IDE in the Dash and start it

The first thing the Ubuntu SDK IDE will do is checking if the environment is properly set up. Unless you are an LXC/LXD power user it is safe to choose 'Yes' in this dialog.

If the Ubuntu SDK is started for the first time, it will open a welcome wizard to help with setting up kits and devices

The best advice after this point is to read each page of the wizard and follow the instructions. It is a fairly easy process.
On the next page the wizard will offer you help to create kits

Push the "Create new Kit" button and read the target creation dialog

At this step we can choose between 3 types of targets:

  • "Build to run on the desktop", will filter for all images compatible with the desktop
  • "Build to run on device or emulator", will filter for all images that can be used for devices
  • "Show all available images", will show all available images

Let's select "Show all available images" to get an overview of all existing images.

As next we choose the preferred target arch. The Ubuntu phones and tablets are armhf and the host PC is either i386 or amd64. So for creating click packages for the phone we will need an armhf target and testing the application on the desktop we will need a native amd64 or i386 target

We can use the default naming for the kits.

Creating an LXD container requires system administrator rights, so at this point we need to authenticate ourself

Once we have entered the right password the download of the LXD image will start

It will take some time, depending on our network bandwidth. Each image is about 400MB. While the wizard downloads and configures the LXD image we have just enough time to read a quick blog post about what the Kits actually are: Everything You Always Wanted to Know About Kits But Were Afraid to Ask . It is not an exaggeration to say that the best way to invest the time is to read that blogpost and understand what the development kits are.

Once the container creation is done a simple dialog will show us some basic details

The next page of the wizard will help to set up target devices. In our case we already had a bq (krillin) phone and an emulator from the rc-proposed channel.

But even if there is no phone, tablet or emulator device available it is safe to finish the wizard.
At this stage the IDE will automatically discover the LXD container and offer us to update it.

It is not a mandatory step and perfectly safe to cancel that dialog.

After finishing the wizard the IDE will open up



Read more
David Callé

A new version of Snapcraft, the tool to create snaps to distribute your software, was recently released: Snapcraft 2.10 is packed with new features and improvements, including:

  • The ‘snapcraft init’ command now produces a template to bootstrap developers to create their snaps and uses ‘devmode’ as the default confinement mode
  • Added support for zip files, which can now be used as a source to be snapped for most Snapcraft plugins.
  • Renamed the ‘strip’ step to ‘prime’. Use of ‘strip’, the former snap lifecycle step, will print deprecation warnings
  • Initial backend support to work on the parts ecosystem
  • Migration to macaroons for authentication. The decentralized, cloud-aware authentication system will enable the addition of more features to talk to the Ubuntu Store APIs and a better developer experience. After this change, developers will need to do a one-off relogin to do uploads
  • A new ‘assumes’ field, which will be used by snapd to assert certain features are supported by the system for a particular snap to work properly
  • General polish around command output and error messages
  • Improvements to the Go and nodejs plugins

Check out the full details on all bug fixes and new features in Snapcraft 2.10.

Install Snapcraft

On Ubuntu

Simply open up a terminal with Ctrl+Alt+t and run these commands to install Snapcraft from the Ubuntu archives on Ubuntu 16.04 LTS

sudo apt update
sudo apt install snapcraft

On other platforms

Get the Snapcraft source code ›

Craft your snaps!

There is a thriving community of developers who can give you a hand getting started or unblocking you when creating your snap. You can participate and get help in multiple ways:

Last but not least the Snapcraft team would like to thank all the contributions from our community, keep them coming!

What’s next?

Next release, 2.11, will include improved documentation and getting started utilities. Subsequent releases will focus on the parts ecosystem, plugins, pull sources, and better integration with the Ubuntu Store for registration, uploads and snap releases.

Read more
Daniel Holbach

In Snappy Playpen we want to bring people together who want to create snaps, document best practices, learn from each other and have fun.

In our first Snappy Playpen event last Tuesday we simply wanted to bring people together, invite them to get to know the team, get started together and see how things go. It went great, check out the report!

Next week, on Tuesday, 14th June, we want to meet up and snap software together again. Obviously you can join #snappy on Freenode or the playpen gitter channel (or contribute to Snappy Playpen) at any time, but on Tuesday we want to get everyone together and make another push to get good stuff landed together.

This time we want to especially extend the invitation to all upstreams who are interested in getting their software snapped. If you are interested and need help, join us and we will figure out things together. If you still need to be convinced, here are a few reasons why this might make sense for your project:

  • Just run snapcraft upload to upload a snap to the store. (Maybe even hook it up with your CI?)
  • No lengthy review process. Publication within seconds.
  • Use different channels (stable, beta, edge) to ship different versions of your software to different audiences.
  • Build instructions in snapcraft.yaml are very simple, all nice and declarative.
  • Millions of Ubuntu 16.04 users can easily install your software through the software center.

We would also like to invite all Ubuntu flavours to participate. If you want to play around with snaps, we will help you get started.

  • WHAT: Snappy playpen sprint
  • WHEN: Tuesday, 14th June 2016 all day
  • WHERE: Join us on gitter or IRC

Read more
David Callé

We announced the Snappy Playpen a few days ago and yesterday was the Kickoff event where we basically invited everyone who was interested, brought in a lot of snapd and snapcraft experts and started snapping software together.

It was simply beautiful to see the level of excitement, the collaboration, how people got to know each other and how much stuff got done. Big hugs to everyone involved - great work!


Along with the usual #snappy IRC channel on Freenode, we used as an experiment and it worked out well. We had at least 40 people participating there (many more on IRC and the mailing list), 850 messages in gitter alone and even after 24 hours we're still working our way through some software to go into the Playpen repository.

Without further ado, here's what already landed in the Snappy Playpen since yesterday:

Landed in the playpen:

Another beautiful thing which landed is Vincent Jobard's French video tutorial about Snapcraft just in time to celebrate the kickoff.

We have many great things which are still work in progress:

Not targeting the Snappy Playpen, but still nice snaps we worked on together as a team:

We also used this time to improve our crowdsourced docs on AskUbuntu:

The Snapcraft mailing-list has been buzzing with questions, answers and discussions:

And of course, kudos to the experts who managed to be very active and helpful, while preparing new releases of snapd and snapcraft.

Until the next Playpen event, which will be more focused on a specific software/framework/technology, we encourage you to have a look at all the snaps and snapcraft recipes available in the repo. Git clone it, cd into a project and run snapcraft to see how all the pieces are coming together to create a snap.

If you are the upstream of one of the above apps, help yourself with these branches and get in touch with us on IRC (freenode/#snappy), Gitter or on the mailing-list so we can provide support if needed.

Read more
Daniel Holbach

Announcing the Snappy Playpen

With snaps and the store, it finally became easy again to publish software in Ubuntu. Snappy Playpen is a project in which we want to collaboratively snap software, learn from each other and document best-practices.

Snappy Playpen is on Github and it's where we want to work together on snapping new software. This will provide excellent examples to new users of snapcraft, we will be able to document best practices, learn from each other and create an incubator for new snaps to be added to the store.

Snappy Playpen won't be a collection of production-ready snaps, we are treating it a bit like a combination of research project and documentation.

If you are curious, just check out our main github page and read the docs there. It's easy and we're quite accessible. Find us on gitter, IRC or the mailing list to find out how to get involved.

You can get started at any time and contribute whatever you feel makes sense, but we want to host themed "sprint" weeks as well. If you have suggestions (e.g. a IoT-related week, a KDE-related week, server app, etc.), let us know. For those weeks we will make sure we have experts there to help us figure this out together.

Next week will be our first Snappy Playpen sprint and it will be a "free for all" week. This will help us to figure out the details and learn about what you all exactly want to do.

On Tuesday, 7th June 2016, we will make a big push and make sure our snapd and snapcraft engineers are there to answer questions and help figure out solutions together. Mark the day in your calendar and check out our docs to find out how to get started.

  • WHAT: Snappy playpen sprint
  • WHEN: Tuesday, 7th June 2016 all day
  • WHERE: Join us on gitter or IRC

Read more
liam zheng

Ubuntu手机现在迎来第十一个重要更新:OTA-11,这次更新的亮点主要为Wifi Display(无线投射模式),借助Wifi Display的功能用户可以体验无线投射屏幕加桌面融合(convergence)的巨大便利。只要将Ubuntu手机连接至显示器或电视,桌面版的Ubuntu模式即可使用,一个移动设备可变身集多窗口模式的全尺寸桌面。目前该功能仅支持魅族PRO5 Ubuntu版,后续还将支持其他型号Ubuntu手机。

Ubuntu手机今天迎来第十一个重要更新:OTA-11,这次更新主要的亮点为Wifi Display(屏幕无线投射),借助Wifi Display的功能用户可以体验无线投射屏幕加桌面融合(convergence)的巨大便利。只要将Ubuntu手机连接至显示器或电视(需要支持Miracast),桌面版的Ubuntu界面即可使用,一个移动设备将变身集多窗口模式的全尺寸桌面环境。目前该功能仅支持魅族PRO5 Ubuntu版,后续还将支持其他型号Ubuntu手机。


Wifi Display:点击观看

Wifi Display使用的是魅族PRO 5 Ubuntu版内建的p2p(peer-to-peer)连接方式启动Ubuntu桌面模式,如直接将手机通过Wifi连接显示器或电视,那么手机将充当触摸板的功能,如已连接蓝牙鼠标、键盘,则将拥有传统桌面模式的体验,重要的是,手机的短信、电话功能可展现在外接显示器上。



在OTA-11以前,Unity 8 Dash的Scope只能竖屏显示。而在OTA-11更新后,Scope将可以横屏显示,对于喜欢横屏的用户来说又多一个选择。并且主页Scope(今日、Nearby)会在解锁屏幕前完成更新,解锁屏幕后可获取最新的信息。



Ubuntu 手机OTA-11又一新特点是支持繁体中文输入法——注音键盘布局。可通过设置——语言&文字——键盘布局,选择注音输入法即可使用。



桌面融合(convergence)作为Ubuntu手机的杀手锏功能,已经让给很多经常背包的用户减轻不必要的负担,作为开发者而言,Unity 8用户界面将支持DGU(dynamic grid units),在开发应用和Scope时更简单,一次开发就可以在多个显示端自动适配。



OTA-11是BQ M10 Ubuntu版的第一个大版本更新,改善操控体验,图形处理,提示性能。



  • 地理位置服务改善,获取地理位置更加准确;

  • 网络管理器更新到1.2版,在上网时更加安全;

  • 应用程序支持多窗口显示(M10桌面融合);

  • UITK滚动条设计更新,Head支持副标题;

  • VPN支持用户名和密码认证;

  • 浏览器应用改进;支持google hangout,重新设计的权限提示对话框;

  • 在桌面融合模式蓝牙鼠标反应更敏捷;

  • 修复了以下bug:语言包翻译,性能问题,自定义通知声音

Read more
Zoltán Balogh

Can I haz MainView in a Window?

When using Unity8 these days connecting a Bluetooth mouse to a device enables windowed mode. Another option is to connect an external monitor via HDMI and most recently on some devices wireless displays. This raises a few questions on the API side of things.

Apps are currently advised to use a MainView as the root item, which can have a width and a height used as the window dimensions in a windowed environment - on phones and tablets by default all apps are always full screen. As soon as users can freely resize the window, some apps may not look great anymore - QtQuick.Window solves this by providing minimum/maximum/Width/Height properties. Another question is what title is used for the window - as soon as there is more than one Page that's no longer obvious and it's actually somewhat redundant.

So what can we do now?

There’s two ways to sort this that we’ll be discussing here. One way is to in fact go ahead and use MainView, which is just an Item, and put it inside a Window. That’s perfectly fine to do and that’s a good stop-gap for any apps affected now. To the user the outcome is almost the same, except the title and sizing can be customized behind the scenes.

import QtQuick 2.4
import QtQuick.Window 2.2
import Ubuntu.Components 1.3
Window {
    title: "Hello World"
    MainView {
        applicationName: "Hello World"

From here on after things work exactly the same way they did before. And this is something that will continue to work in the future.

A challenger appears

That said, there’s another way under discussion. What if there was a new MainWindow component that could replace the MainView and provide the missing features out of the box? Code would be simpler. Is it worth it, though, just to save some lines of code you might wonder? Yes actually. It is worth it when performance enters the picture.

As it is now, MainView does many different things. It displays a header for starters - that is, if you’re not using AdaptivePageLayout to implement convergence. It also has automaticOrientation API, something the shell does a much better job of these days. And it handles actions, which are, like the header, part of each Page now. It’s still doing a good job at things we need, like setting up folders for confinement (config, cache, localization) and making space for the OSK (in the form of anchorsToKeyboard). So in short, there’s several internals to re-consider if we had a chance to replace it.

Even more drastic would be the impact of implementing properties in MainWindow that right now are context properties. “units” and “theme” are very useful in so many ways and at the same time by design super slow because of how QML processes them. A new toplevel component in C++ could provide regular object properties without the overhead potentially speeding up every single use of those properties throughout the application as well as the components using them behind the scenes.

Let’s be realistic, however, these are ideas that need discussion, API design and planning. None of this is going to be available tomorrow or next week. So by all means, engage in the discussions, maybe there’s more use cases to consider, other approaches, it’s the one component virtually every app uses so we better do a good job coming up with a worthy successor.

Read more
Zoltán Balogh

In the recent days there was lots of discussion about the versioning of the Ubuntu UI Toolkit. Finally we thought that the topic deserves a dedicated blog post to clarify the situation and resolve some misunderstandings.

Let’s start with  the background story.

The UITK releases, before we opened the 1.3 branch for development, was mainly targeting touch devices and their main objective was to offer more or less a complete API set for mobile application development. The versions prior to 1.3 were working on the desktop too, but they were clearly suboptimal for those use cases because for example they were missing mouse and keyboard capabilities

With the 1.3 development branch we set on a single goal. With this release the UITK will offer a feature complete API set for devices of all form factors with all kinds of capabilities. It means that applications built for the 1.3 UITK will work on a touchscreen device with a small display just as on a large screen with mouse and keyboard. It was a very ambitious plan, but absolutely realistic.

We have decided that we follow the "release early and release often" principle so developers will have time to adapt their applications to the new APIs. At the same time we promised that whatever API we release will be supported for at least one minor revision and we will follow a strict and developer friendly deprecation process if needed.

It means that even if the source code of the 1.3 UITK is not frozen, all APIs released in it are stable and safe to use.

So far we did keep our promise. There was not a single application in the store or in the archive  that suffered functional regression due to an intentional API break in the UITK. True, UITK has bugs. True, one can argue about if changing the color palette classifies to be an API change or not.  Not to mention the awkward situation when an application takes advantage of a bug in the UITK and loses that advantage when the bug gets fixed. Also we have seen broken applications because they were using private APIs and properties.

It is absolutely true that using a frozen API set is the safest for application developers. No doubt about it and I do hear the opinions that some developers wish to see a fully frozen 1.3 UITK. We do wish the same.

Now, let us visit this idea and check a bit around. I do promise that folding out the big picture will help everyoneunderstand why the UITK is developed in the way it is.

So, let us say we freeze the 1.3 UITK today.  In that case we need to open the 1.4 branch plus we would certainly open a Labs space. Before going any further let me list what kind of changes we do in the UITK codebase:

  1. Critical bug fixes. Right, I am sure that nobody argues the fact that once we found or reported a critical bug we have to push a fix to the supported releases as soon as possible. At this very moment we have a good number of open bug reports. About 80% of the merged branches and patches to the UITK code are bug fixes. With every OTA release we push out 10-20 critical bug fixes. It means that each bugfix needs to target both the frozen and the development branch, plus the labs space. From the point of bug fixes it is important that the supported branches of the UITK do not diverge too much. One may say 1.3 should be frozen, so no bug fixes should go there, eventually some showstoppers. However we have way too many of those fixes which we must land in 1.3 as well. Fragmenting the UITK and so the platform at this early stage might fire back later.

  2. Feature gaps for convergence. As we have stated many times, the convergence features are not yet completely implemented in the UITK. We do wish they were, but sadly  they are not. It means that almost every day we push something to the UITK codebase that makes that feature gap smaller. In case we freeze the 1.3 UITK we can push these convergence features only to the 1.4 and the labs space. That would mean that all core applications would need to migrate to the 1.4 UITK because they are the primary consumers of the convergence feature.

  3. UITK uses dynamic styling of components. The styles are loaded from a specified theme matching the version of the UITK module the component is imported from. This is necessary because themes implement UX including behavior and looks, so just like functions in the API developers may rely on theming when designing their apps, or even adding custom components. We are using the property cache to detect the version of the module. As we are not planning any API additions to StyledItem, moving to 1.4 would require us to declare a dummy property just to be able to detect that the component is imported from the 1.4 version. Introducing a property just to be able to differentiate doesn’t sound really professional. Yes, the version could be set in the component itself, but that would immediately break the symlink idea (second time) and beside that, noone guarantees that the version will be set prior to the style document name, so a dual-style loading can be eliminated. We had this API in the first version of the sub-theming, but was removed, and perhaps it was the only API break we did in 1.3 so far.

  4. Unit tests are also affected. They need to be duplicated at the least when components in 1.4 diverge in behavior and features - but even bugs in superclass A altered in 1.4 may affect component B which is not altered and still fail test cases. On the other hand Autopilot is not so flexible. While the CPOs (Custom Proxy Objects, the classes that represent QML components in Python test cases) basically do not care about the import versions, they do have problems with the API differences, and it is not so easy doing differentiation for the same component to detect which API can be used in what context. We’ve been discussing to try to move as many tests as we can to QTest (unit tests), however there are still tons of apps using Autopilot, and we have to provide and maintain CPOs for those.

  5. The upcoming Labs space will hold the components and APIs that we do not promise to be stable and are subject to change even in one minor version. We need this space to experiment with features and ideas that would not be possible in a stable branch.

If we look at this picture we will see immediately that the further we go with closing the feature gaps the more we diverge from the codebase of the frozen 1.3.  Note that code change does not mean API change! We are committed to stable APIs not to stable code. Freezing code is a luxurious privilege of very mature products. Implementing new features and fixing critical bugs in two different branches would mean that we need to fork the UITK. And that itself would bring issues which have not been  seen by many. A good example for this is the recently discovered incompatibility issue between the old style header and the refactored (to be implemented in C++) AdaptivePageLayout. To gain the performance improvements in 1.3 it’s necessary to change the component completely. Furthermore if only 1.4 started off with a rewritten AdaptivePageLayout fixing bugs would consume considerable time in two entirely different codebases at that point.

It is important to note that the UITK comes in a single package in a single library. Forking the UITK package is clearly not an option. The applications do not have control over their dependencies. Also creating multiple libraries for different versions is not an option either. Providing the UITK in a single plugin has some consequences. Many of the developers asked why there are no more frequent minor version bumps. The answer is simple. As long as all the versions come in a single plugin, each and every minor release will increase the memory consumption of the UITK. Bumping the UITK version 3-4 times a year would end up in a 10-12 times bigger memory footprint in just two years. We do not want that. And most probably when we “release” 1.4, we will need features from Qt 5.6, which means we need to bump imports in all our QML documents to 2.6. So it is a nice theory but it is not a working one.

To summarize the whole story, we are where we are for good reason. The way the UITK is versioned, packaged and provided to the application developers is not accidental. At the same time we do admit that after measuring the costs and benefits of different paths, we had to make compromises. The present so called rolling 1.3 release is safe to use, the APIs provided by the UITK are all stable and supported. But as it is still evolving and improving  it is a good idea to follow the news and announcements of the SDK developer team. We are available pretty much 24/7 on the #ubuntu-app-devel Freenode channel, on mailing list, on Telegram and on all commonly used public platforms. We are happy to listen to you and answer your questions.

Read more
liam zheng






与往期黑客松活动不同的是,本次黑客松除了手机应用开发,特意加入了Convergence应用开发内容。现场共有8个小组参赛,码出了9个作品。游戏、创意原生应用一应俱全,还能在最新的BQ M10 Ubuntu版平板上运行。下面进入应用介绍环节:

Demo 1:死生忍者和疯狂赛车,基于HTML5的游戏,可玩性非常强,界面设计精美,可在Ubuntu手机、平板上流畅运行。


Demo 2:Amap,基于Scope的地图应用,使用高德地图API,可实现搜索地理位置,选择公交、步行的导航方式。

Demo 3:汤姆猫,最为熟悉和非常有趣的语音互动游戏。

Demo 4:水果侦探,由团队设计、开发的独立游戏,拥有排名机制,拥有很好的交互性和游戏性。

Demo 5:Ubuner,基于Scope的打车服务应用,可通过搜索地理位置,呼叫Uber司机使用打车服务。

Demo 6:Tuner ,原生应用,配合Ubuntu手机可为尤克里里、吉他调音,实用价值非常大。

Demo 7:Ubuntu 2048,数字游戏,界面上加入操作特效,并拥有排名机制。

Demo 8:Redheart,拥有AI功能的红心大战游戏,在平板上可流畅运行,游戏难度可调。



Read more
Christian Dywan

With OTA-11 on the horizon, rc-proposed now has a new framework. If you want to use the latest UI Toolkit API, that is part of Ubuntu.Components 1.3, you should bump your framework to 15.04.5 - in QtCreator you can find your under Other Files and simply select the new version. Now you can use the new subtitle property with PageHeader which complements the existing title and shows a smaller label at the bottom of the header. PageHeaderStyle gains subtitleColor which can be used via StyleHints to customize the looks of the new subtitle. disabledForegroundColor further more now allows changing the color of the actions when the header is disabled. For example

Page {
    header: PageHeader {
        id: pageHeader
        title:"Hello World")
        subtitle:'Lorem ipsum dolor sit amet')
        StyleHints {
            backgroundColor: UbuntuColors.inkstone
            // The color of disabled actions
            // The divider at the bottom
            // The new subtitle
        trailingActionBar.actions: [
            Action {
                iconName: 'list-add'
                onTriggered: console.log('Hello world')
           Action {
              iconName: 'list-remove'
              enabled: false

"enabled: false" in the Action turns it red as it no longer responds to touch, mouse or keyboard input (the same can be done for all actions by disabling PageHeader).

Remember OTA-10 and framework 15.04.4?

Already shipping on most if not everyone’s Ubuntu devices now is OTA-10 which brought with it new API for the BottomEdge component: preloadContent. This new boolean property when set to true causes all contents to preload in the background even before the hint is being used to reveal it - the default is false, which means contents are loaded on demand like before. This can speed things up a great deal in some cases.

BottomEdge {
    id: bottomEdge
    height: parent.height -
    hint.text: “My bottom edge”
    preloadContent: true
    contentComponent: Rectangle {
        width: page.width
        height: page.height


Read more