Canonical Voices

Posts tagged with 'article'

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
liam zheng

我们与我们的物联网业务主管 Maarten 进行了一次有趣的聊天。大家畅谈了投影仪与支持应用的软件无线电 ( 相遇会发生什么。下面就是它们的结合带来的一些很酷的玩法,包括通过手势与无人机交流、进入无线电对讲机系统以及开辟实际上并不存在的覆盖区域。

我们与我们的物联网业务主管 Maarten 进行了一次有趣的聊天。大家畅谈了投影仪与支持应用的软件无线电 ( 相遇会发生什么。下面就是它们的结合带来的一些很酷的玩法,包括通过手势与无人机交流、进入无线电对讲机系统以及开辟实际上并不存在的覆盖区域。

  • 使用软件无线电 (SDR) 接收电视广播,并使用投影仪作为电视屏幕

  • 添加 WiFi 应用但不必多交一部设备的电费

  • 添加 4G 应用,通过 REST API 获取电信提供商的频谱,并为建筑物内没有信号的地方提供信号覆盖

  • 探测进入房间的人是否随身携带了手机并开启投影仪,在周围没有人时关闭投影仪。如果照明、供暖等设备可通过 API 来控制,那么这些设备也包括在内

  • 创建你自己的物联网无线协议,从而可以连接房子周围的感应器,并将带有实时数据的仪表板投影到屏幕上

  • 使用支持蓝牙的手势感应器探测手的动作,通过手势与无人机或玩具车交流并控制它们,将无人机或玩具车看到的东西投影到屏幕上观看

  • 使用 3 台投影仪,根据每个人的蓝牙或手机信号以三角法定位每个人在办公室内的行动位置。连接他们的在线日历,按照他们的日程安排自动打开 Webex 或 Google Hangout。连接室内的无线监控摄像头,将监控画面传送给其他会议邀请。使用内置麦克风收听会议所讲的全部内容

  • 通过港口的 AIS 信号传输设备跟踪船舶航行或通过 Mode S 跟踪飞机飞行,并通过投影仪显示在 Google Map 上绘制的船舶和飞机航线

  • 通过直接式胎压监测系统 (TPMS) 将车辆状态的实时数据投影到屏幕上

  • 与诸如无线电对讲机的各类 2.4GHz 设备通话,以及通过投影仪连接婴儿监视器来显示婴儿当时的活动

  • 构建你自己的低功率 WAN 接收器解决方案(例如 LoRA),并在屏幕上显示接收到的内容


Read more
liam zheng




我们的演示将是一个可以让你方便在家庭网关(Home gateway)上部署其他应用的app。让你直观感受智能手机和家庭机器人之间是如何交流、通信从而为你服务的。当你到家时,机器人将用摄像头来识别是你回来了,同时麦克风也可以提供语音交互。

除此,你还可以部署其他app在家庭网关上,包括一个接入点(家庭WiFi),视频服务,本地的服务器(比如Skype和Google Hangout的数据都存储在本地),自动化家用设备等。


Read more
liam zheng


英国最大的移动运营商 EE(现已归属 BT 旗下)近日宣布,将与新一轮开源移动网络技术大潮领导者之一的 Lime Micro 以及 Canonical (Ubuntu) 合作,共同确保英国实现更好的移动网络覆盖。

英国最大的移动运营商 EE(现已归属 BT 旗下)近日宣布,将与新一轮开源移动网络技术大潮领导者之一的 Lime Micro 以及 Canonical (Ubuntu) 合作,共同确保英国实现更好的移动网络覆盖。

EE 正在大力投资网络建设,争取到 2020 年实现 95% 的 4G 网络地理覆盖率。但是,并不是所有地区都可以或者都适合建造新的大型信号塔。他们想充分利用现有基础设施,例如灯塔、高层建筑、山岭等等。另外的一大难题是,依靠现有手段覆盖偏远地区在经济上或技术上是不可行的。正因为如此,EE 才选择与技术创新公司合作开发成本更低、体积更小、弹性更高、效果更好的解决方案。

Lime Micro 即将以众筹形式推出首款支持应用的开源软件无线电,即 LimeSDR。通过 4G 应用,LimeSDR 将构成一个功能完善的基站的基础。将这个基站安装到热气球或无人机上,可以覆盖通过其他方式难以到达的地区。另外,将这些基站嵌入自动售货机、银行设施、智能灯杆、数字标牌等其他用途的设备内部,还将降低部署连接的成本。

EE 希望偏远社区也能加入网络建设当中。这些社区可以提出他们需要的功能,甚至可以参与网络的维护。这可以让社区与运营商以全新的方式合作。并且有了当地人的支持,甚至可以减少受过培训的技术人员长途跋涉解决问题的需要。例如,如果一个基站只是需要重新启动,那么派遣一位工程师从爱丁堡跋涉 300 英里前往诸岛将是一件很不经济(或者不切实际)的事情。

EE 将在英国多所大学举办挑战赛,鼓励大家集思广益,就如何连接未联网地区和降低运营成本提出更多创新和开源的想法。任何有好创意的人都可以参加。Ubuntu Core 具有开源、支持应用和随时可用于生产的特点。你只要购买一个 LimeSDR,下载 Ubuntu Core,就能向世界展示你的应用或设备可以怎样降低网络运营成本。帮助未联网地区实现网络覆盖将促进经济发展,因此你的努力将会造福我们的社会。我们非常期待看到你如何将无线网络的未来变得更加美好.

LimeSDR Crowd Supply 宣传视频(优酷)

Read more
April Wang

Ubuntu 手机平台的快速发展及其向物联网IoT和各种设备的广泛延伸,要求我们必须解决安全性和可靠性的实际问题。这些挑战同样存在于台式机和服务器系统平台,并令想使用长期支持版本来运行较新软件的用户和开发者感到格外烦恼。这促使我们开发了 snap 打包格式和工具。

在 Ubuntu 16.04 LTS 中,用户将可以同时安装 snap 包和传统的 deb 包。这两种打包格式可以和谐共存,并使我们能够保持现有的操作系统开发和升级流程。这种做法巩固了我们与 Debian 社区的关系,同时也使广大开发者和社区可以根据需要为 Ubuntu 用户发布 deb 应用或 snap 应用。

利用 snap 软件包,开发者可以为 Ubuntu 16.04 LTS 带来更新版本的应用。较新版本的 KDE、GNOME、浏览器或其他桌面环境应用通常很容易在较旧版本的 LTS 上构建,但是打包和提供更新的复杂程度令我们过去无法提供这类应用。

snap 包的安全机制让我们可以开放平台并在各个分支版本间更快地迭代,这是因为 snap 应用与系统的其余部分是隔离的。用户可以放心安装 snap 而不必担心会对系统或其他应用造成影响。同样,开发者可以自己决定为其应用打包的库的具体版本,从而更好地掌控更新周期。事务性更新使 snap 软件包的部署更加稳定和可靠。

通过在 Ubuntu 16.04 LTS 中加入 snap 软件包支持,我们使 Ubuntu 开发者拥有统一的体验,无论他们是为 PC、服务器、手机还是物联网设备开发软件。Snapcraft 是面向 snap 开发推出的一款工具,可帮助开发者轻松打包应用和依赖项。以 snap 软件包为目标的开发者将获得一个极佳的环境来直接在桌面上编写和测试他们的应用,而不必使用某个设备或虚拟机。

付费应用的开发者通常不得不管理各种库之间的依赖关系和兼容性,特别是在较旧版本的 Ubuntu 上,这令他们颇感烦恼。出于这个原因,这些应用将于 2016 年秋季从 deb 迁移到 snap。Canonical 将与开发者社区一同努力,在未来几个月内提供工具、培训和文档来支持大家顺利完成过渡。

虽然这对于 Ubuntu 社区来说一项重大的新功能,但这并不会使我们丧失传统。16.04 及后续版本仍将继续支持数以万计的所有 .deb 格式的应用和软件包,特别是将会继续提供 deb 档案文件,以供所有人使用和分发软件。

如果您想进一步了解在经典 Ubuntu 上使用 snap 的更多信息或对此有任何疑问,请访问 参加我们近期举办的以下活动:

Snaps on classic Ubuntu Q&A with Olli Ries,4 月 14 日星期四 15:00(UTC 时间)

Snappy Clinic,4 月 26 日星期二 15:00(UTC 时间)

像往常一样,您可以通过 邮件列表参与讨论,或在 Ask Ubuntu 上提出和解答有关 snappy 的问题。

原文作者:Olli Ries  最早发布时间:2016 年 4 月 13 日,原文网址

Read more

As much anticipated, this week Ubuntu 16.04 LTS was released with integrated support for snaps on classic Ubuntu.

Snappy 2.0 is a modern software platform, that includes the ability to define rich interfaces between snaps that control their security and confinement, comprehensive observation and control of system changes, completion and undoing of partial system changes across restarts/reboots/crashes, macaroon-based authentication for local access and store access, preliminary development mode, a polished filesystem layout and CLI experience, modern sequencing of revisions, and so forth.

The previous post in this series described the reassuring details behind how snappy does system changes. This post will now cover Snappy interfaces, the mechanism that controls the confinement and integration of snaps with other snaps and with the system itself.

A snap interface gives one snap the ability to use resources provided by another snap, including the operating system snap (ubuntu-core is itself a snap!). That’s quite vague, and intentionally so. Software interacts with other software for many reasons and in diverse ways, and Snappy is a platform that has to mediate all of that according to user needs.

In practice, though, the mechanism is straightforward and pleasant to deal with. Without any snaps in the system, there are no interfaces available:

% sudo snap interfaces
error: no interfaces found

If we install the ubuntu-core snap alone (done implicitly when the first snap is installed), we can already see some interface slots being provided by it, but no plugs connected to them:

% sudo snap install ubuntu-core
75.88 MB / 75.88 MB [=====================] 100.00 % 355.56 KB/s 

% snap interfaces
Slot                 Plug
:firewall-control    -
:home                -
:locale-control      -
:opengl              -
:timeserver-control  -
:timezone-control    -
:unity7              -
:x11                 -

The syntax is <snap>:<slot> and <snap>:<plug>. The lack of a snap name is a shorthand notation for slots and plugs on the operating system snap.

Now let’s install an application:

% sudo snap install ubuntu-calculator-app
120.01 MB / 120.01 MB [=====================] 100.00 % 328.88 KB/s 

% snap interfaces
Slot                 Plug
:firewall-control    -
:home                -
:locale-control      -
:opengl              ubuntu-calculator-app
:timeserver-control  -
:timezone-control    -
:unity7              ubuntu-calculator-app
:x11                 -

At this point the application should work fine. But let’s instead see what happens if we take away one of these interfaces:

% sudo snap disconnect \
             ubuntu-calculator-app:unity7 ubuntu-core:unity7 

% /snap/bin/ubuntu-calculator-app.calculator
QXcbConnection: Could not connect to display :0

The application installed depends on unity7 to be able to display itself properly, which is itself based on X11. When we disconnected the interface that gave it permission to be accessing these resources, the application was unable to touch them.

The security minded will observe that X11 is not in fact a secure protocol. A number of system abuses are possible when we hand an application this permission. Other interfaces such as home would give the snap access to every non-hidden file in the user’s $HOME directory (those that do not start with a dot), which means a malicious application might steal personal information and send it over the network (assuming it also defines a network plug).

Some might be surprised that this is the case, but this is a misunderstanding about the role of snaps and Snappy as a software platform. When you install software from the Ubuntu archive, that’s a statement of trust in the Ubuntu and Debian developers. When you install Google’s Chrome or MongoDB binaries from their respective archives, that’s a statement of trust in those developers (these have root on your system!). Snappy is not eliminating the need for that trust, as once you give a piece of software access to your personal files, web camera, microphone, etc, you need to believe that it won’t be using those allowances maliciously.

The point of Snappy’s confinement in that picture is to enable a software ecosystem that can control exactly what is allowed and to whom in a clear and observable way, in addition to the same procedural care that we’ve all learned to appreciate in the Linux world, not instead of it. Preventing people from using all relevant resources in the system would simply force them to use that same software over less secure mechanisms instead of fixing the problem.

And what we have today is just the beginning. These interfaces will soon become much richer and more fine grained, including resource selection (e.g. which serial port?), and some of them will disappear completely in favor of more secure choices (Unity 8, for instance).

These are exciting times for Ubuntu and the software world.


Read more
Community Team

The squirrel has landed!

Today, we are proud to bring you our 6th Long Term Support release: Ubuntu 16.04 LTS. It is the sum of the work of thousands of people collaborating all over the world, working tirelessly for the last six months and we'd like to share a few highlights.

Ubuntu 16.04 LTS is here!

Software distribution

You have probably already heard about this: we are bringing a new package format for you to start distributing your apps. It's called snap and it allows you to deliver software to users without going through the traditional Ubuntu archive inclusion process. Whether you are making a game, an utility or the next Firefox, it will enable you to continuously bring the latest version to users. And it’s easy! –it will mostly involve adding a single declarative file to your source tree.

Ubuntu Core and Snapcraft

Snappy Ubuntu Core is the future of Ubuntu, it is built around the snap packaging format and is a brand new world if you are used to classic Ubuntu. Transactional updates, confined apps, smaller and very modular, it’s the Ubuntu for all devices and form factors: your ARM board, your router, your drone, your laptop… your imagination is the limit.

Version 2.0 has just been released, and we’ve collected the highlights from the development team to get you started:

This is important for app developers in a multitude of ways. Snappy Ubuntu Core incorporates a lot of the feedback of third party app developers, ISVs and upstream projects we have been getting over the years. What all of them wanted in a nutshell was: a solid Ubuntu base, a lot of flexibility in handling their app and the relevant stack, being mostly independent from distro freezes, dead-simple packaging, bullet-proof upgrades and rollbacks, and an app store model established with the rise of the smartphones. Snappy Ubuntu Core is exactly that and more. What it also brings to Ubuntu is a clear isolation between apps and a universal trust model.

We have been working with the Engineering teams extensively and assisted them in testing the software, making sure that things worked, writing documentation, putting together examples and bootstrapping an initial community.

What we have today is just the start. There are still a number of details to be figured out, which will all land in Ubuntu through SRUs and Ubuntu Core updates.

Phone and Tablet

We have a tablet that converges into a desktop when a bluetooth mouse is detected! It ships some desktop apps by default such as Firefox and LibreOffice and of course, Ubuntu SDK apps. This is an exciting moment for everyone involved as it’s a milestone on the road to full devices convergence: many form factors and architectures, one codebase.

We have released the latest and greatest phone over-the-air update: OTA 10 a few days ago, which - as usual - brings new features and bug fixes, such as:

  • Re-designed Out Of the Box Experience

  • VPN support

  • Easy switching to desktop mode

  • New colour palette

  • New default apps: uNav, Dekko, Calendar

For more, see the release notes.

Here is what to look forward to in OTA 11 and of course, the Ubuntu SDK roadmap for the next 6 months: speed and more convergence.

Community phone ports

Our porting community of volunteers, lead by the indefatigable Marius Gripsgard has been extending the range of devices where Ubuntu can be installed.

Along with the OnePlus One port, a Fairphone 2 port, with great help and support from the Fairphone Engineering team, is on the way. The ubports site and the Porting Guide have all the information on status, how to get started and contribute to new or existing ports.

Developer portal

The Developer Portal is the place to get started with developing apps for Ubuntu, no matter if your primary interest is the phone, IoT devices or Ubuntu in general. Thus we have been supporting the various Engineering and product teams to bring together all app development resources and present them in a coherent and digestible way.

One important update was reflecting the changes in products and priorities. We wanted to make it clearer that the primary choice on the site is the one concerning products. An overview of the related changes (both implemented and planned) can be seen here.

A lot of work was put into importing already existing documentation. Both in terms of guides written by Engineering teams, but API docs as well. As usual in a diverse organisation as Ubuntu they come in various forms and we had to adapt to bring them onto the site without confusing our users. From now on it will be easier to import more API docs from more packages from various frameworks at the same time.

One of the great features of the developer site is that it will allow us to get the imported guides translated as well. This is useful for the docs imported from our Markdown importer, e.g. snappy and snapcraft. Here we almost exclusively rely on the great work of the Engineering teams and work in conjunction with them. The Marketing team has been contributing some more docs recently, which will land on the site very soon. On the snappy side of things, we also automatically import available gadget snaps from the store.

With the amount of information growing and growing, we are looking for ways to provide more clarity next cycle. We would like to make the versioning of documentation more obvious and improve the navigation. Luckily we are not alone in this quest, but are working on this together with the Design and Web teams. And lastly we are looking to landing a new blog engine soon, which is being tested on the Ubucon Site right now.

Community and planning

The next edition of the Ubuntu Online Summit is also coming in 2 weeks –3rd to 5th May. It is an excellent opportunity to meet other community members, plan together the next cycle and learn and provide feedback on the roadmaps of the Engineering teams. We hope to see you there.

We’d like to thank everyone who has helped put together yet again our best release so far: from documenters, to translators, to forum and Ask Ubuntu moderators, IRC operators, advocates, bug triagers, testers, app developers, packagers, artists and more…. here’s to you: happy Ubuntu 16.04!

Read more

As announced last Saturday, Snappy Ubuntu Core 2.0 has just been tagged and made its way into the archives of Ubuntu 16.04, which is due for the final release in the next days. So this is a nice time to start covering interesting aspects of what is being made available in this release.

A good choice for the first post in this series is talking about how snappy performs changes in the system, as that knowledge will be useful in observing and understanding what is going on in your snappy platform. Let’s start with the first operation you will likely do when first interacting with the snappy platform — install:

% sudo snap install ubuntu-calculator-app
120.01 MB / 120.01 MB [===============================] 100.00 % 1.45 MB/s

This operation is traditionally done on analogous systems in an ephemeral way. That is, the software has either a local or a remote database of options to install, and once the change is requested the platform of choice will start acting on it with all state for the modification kept in memory. If something doesn’t go so well, such as a reboot or even a crash, the modification is lost.. in the best case. Besides being completely lost, it might also be partially applied to the system, with some files spread through the filesystem, and perhaps some of the involved hooks run. After the restart, the partial state remains until some manual action is taken.

Snappy instead has an engine that tracks and controls such changes in a persistent manner. All the recent changes, pending or not, may be observed via the API and the command line:

% snap changes
ID   Status  ...  Summary
1    Done    ...  Install "ubuntu-calculator-app" snap

(the spawn and ready date/time columns have been hidden for space)

The output gives an overview of what happened recently in the system, whether pending or not. If one of these changes is unintendedly interrupted for whatever reason, the daemon will attempt to continue the requested change at the next opportunity.

Continuing is not always possible, though, because there are external factors that such a change will generally depend upon (the snap being available, the system state remaining similar, etc). In those cases, the change will fail, and any relevant modifications performed on the system while attempting to accomplish the defined goal will be undone.

Because such partial states are possible and need to be handled properly by the system, changes are in fact broken down into finer grained tasks which are also tracked and observable while in progress or after completion. Using the change ID obtained in the former command, we can get a better picture of what that changed involved:

% snap changes 1
Status ...  Summary
Done   ...  Download snap "ubuntu-core" from channel "stable"
Done   ...  Mount snap "ubuntu-core"
Done   ...  Copy snap "ubuntu-core" data
Done   ...  Setup snap "ubuntu-core" security profiles
Done   ...  Make snap "ubuntu-core" available
Done   ...  Download snap "ubuntu-calculator-app"
Done   ...  Mount snap "ubuntu-calculator-app"
Done   ...  Copy snap "ubuntu-calculator-app" data
Done   ...  Setup snap "ubuntu-calculator-app" security profiles
Done   ...  Make snap "ubuntu-calculator-app" available

(the spawn and ready date/time columns have been hidden for space)

Here we can observe an interesting implementation detail of the snappy integration into Ubuntu: the ubuntu-core snap is at the moment ~80MB, and contains the software bundled with the snappy platform itself. Instead of having it pre-installed, it’s only pulled in when the first snap is installed.

Another interesting implementation detail that surfaces here is the fact snaps are in fact mounted rather than copied into the system as traditional packaging systems do, and they’re mounted read-only. That means the operation of having the content of a snap in the filesystem is instantaneous and atomic, and so is removing it. There are no partial states for that specific aspect, and the content cannot be modified.

Coming back into the task list, we can see above that all the tasks that the change involved are ready and did succeed, as expected from the earlier output we had seen for the change itself. Being more of an introspection view, though, this tasks view will often also show logs and error messages for the individual tasks, whether in progress or not.

The following view presents a similar change but with an error due to an intentionally corrupted system state that snappy could not recover from (path got a busy mountpoint hacked in):

% sudo snap install xkcd-webserver
[\] Make snap "xkcd-webserver" available to the system
error: cannot perform the following tasks:
- Make snap "xkcd-webserver" available to the system
  (symlink 13 /snap/xkcd-webserver/current: file exists)

% sudo snap changes 2
Status  ...  Summary
Undone  ...  Download snap "xkcd-webserver" from channel "stable"
Undone  ...  Mount snap "xkcd-webserver"
Undone  ...  Copy snap "xkcd-webserver" data
Undone  ...  Setup snap "xkcd-webserver" security profiles
Error   ...  Make snap "xkcd-webserver" available to the system

Make snap "xkcd-webserver" available to the system

2016-04-20T14:14:30-03:00 ERROR symlink 13
    /snap/xkcd-webserver/current: file exists

Note how reassuring that report looks. It says exactly what went wrong, at which stage of the process, and it also points out that all the prior tasks that previously succeeded had their modifications undone. The security profiles were removed, the mount point was taken down, and so on.

This sort of behavior is to be expected of modern operating systems, and is fundamental when considering systems that should work unattended. Whether in a single execution or across restarts and reboots, changes either succeed or they don’t, and the system remains consistent, reliable, observable, and secure.

In the next blog post we’ll see details about the interfaces feature in snappy, which controls aspects of confinement and integration between snaps.


Read more
David Callé

After a month of deliberations, it's time to announce the Scopes Showdown 2016 winners!

It's been a blast to see the interaction this contest has generated between scopes developers and the scopes API team, many bugs have been fixed, contributions have been accepted and many suggestions have been considered for inclusion and are now on the roadmap (which will be discussed during the next Ubuntu Online Summit)!

About half of the accepted entries are using the new JavaScript API, which is very exciting, to say the least. All developers have put their heart in these scopes and they all have their merits, but we had to pick the three best and also the one seen as the most innovative...

Thanks to all participants and judges, here are the results!

See the results ›

Read more
liam zheng

Ubuntu手机家族已迎来第四款Ubuntu手机——魅族 PRO5 Ubuntu版,特别举办本次魅族 PRO5 Ubuntu手机黑客松上海站活动。这也是2016Ubuntu黑客松活动的第一站。2016年4月9日,黑客松活动在上海浦东联合创业办公社(张江高科)正式开始,当天吸引了5个主力团队在短短的36个小时内hack出了成果。现场有参加过往届黑客松的开发者,也有第一次参加的码农们,还有在校的大学生。


Ubuntu黑客松上海站与之前的黑客松活动一样,让开发者在有限的时间内完成作品或Demo的开发,在参与活动的同时开发者结实更多朋友,分享开发经验,活动、社交两不误。活动正式开始后,开发者们开始互相交流,或向现场工程师咨询开发中遇见的问题。在上海站获得中,解决了一个开发者在安装Ubuntu SDK中安装chroot问题,如果你也碰到这个问题,不妨查阅下该方法。经过36个小时的奋斗、努力,开发者小组们完成了3个作品(Demo),并将其安装到Ubuntu手机上做演示,分别:Uper开发工具,一款可以简化Ubuntu手机开发的工具;chess Ubuntu手机下流畅运行的国际象棋游戏;股票大师Scope,在Scope上浏览最新的股票资讯。







上海站Ubuntu手机黑客松还邀请到了Techcrunch CEO卢刚、猫科技媒体运营斯文前来活动现场担当比赛评委。在开发者对作品进行介绍和演示后,评委最终评定3个团队可获得黑客松奖项。也许你因地域或其他原因不能来现场参加黑客松活动,在这里做一个预告:下一场黑客松即将开始,期待你的参与!




对于Ubuntu手机应用开发,不仅是开发一个应用,而是一个熟悉Ubuntu桌面、手机的机会。为了方便开发者轻松开发Ubuntu手机应用,Ubuntu在赛前会举行在线视频培训,介绍Ubuntu 手机SDK安装、配置,以及开发案例,这样让开发者提前熟悉Ubuntu SDK,做好开发,不仅有在线视频培训,活动现场也有经验丰富的软件工程师进行指导。

Read more
liam zheng



这是Ubuntu手机从去年上市以来, 第10次系统更新。这次OTA-10版本更新中有以下几项重大新特征。









谈到网络,OTA-10另一项改进就是对默认浏览器应用的优化。在手机或平板触控模式下,可使用长按操作呼出选择器功能,选择网页内容进行复制/粘贴。在桌面融合模式下,终端打开的某个网页链接,系统会自动开启浏览器应用并打开一个新的页面, 而不是另外再打开一个浏览器应用。不仅如此,当手机、平板连接到鼠标后,浏览器底部提示自动变成可点击的侧边栏。除了上面的功能,还针对内存占用进行了优化。















Read more
Zsombor Egri

In 2012 we started the Ubuntu UI Toolkit development with QML-only components, all logic being provided in Javascript. This allowed us to deploy components quickly, to do fast prototyping, and tweak the behaviors and look-and-feel on the fly without the need to re-package or rebuild the entire toolkit. With all its benefits, this approach revealed its negative side, which is the impact on the performance. Complex applications are the most affected, which use many components, and their startup as well as rendering time is heavily affected by the component performance.

Then came the theming, the grid units, and the i18n localization, which introduced the plugin. The theming engine was the only component implemented in C++ as we knew from the beginning that we needed to be fast on loading and especially applying the styles on components. The style loading was done in QML using loaders, which kept the flexibility on tweaking. After several attempts on optimizing the engine, we decided to refactor it, and we managed to come up with a theming that was little more than twice as fast as the previous one. Although we started to gain speed on components initialization, components were still too slow to be applicable in kinetic scrolling. List views were still laggish, delegate creation of the simplest ListItem module component was still 60 times slower than of an Item. Therefore we decided to move components to C++ one by one, especially the ones on the critical path. StyledItem was one of the first, followed by a new ListItem component, which by now you are all familiar with. So it became crystal clear that, if we want you guys to be able to play with full QML apps and still have decent performance in your apps, we must provide at least the core logic of the components in C++, and do the styling in QML. This thought was confirmed also by the Qt developers, when they announced the start of the next generation of the Qt Quick Controls.

But let’s take the biggest issues that brought us to press the reset button.


When a person takes a toolkit in his/her hand, the first thing (s)he will encounter is the API. Are the component names self-explanatory, is the API easy to use, no ambiguities when using it, etc, etc. Many developers do not read the API docs, they just jump in and start running the example codes, copying the examples from the documentation without reading a line from it. And next, they will try experimenting on the components, start changing properties, add functionality to the code, and so they start shaping their ideas for their apps.

I think API wise we are in a pretty good shape, we tried to be as close to the declarative QML world as possible, and follow the practices imposed by the Qt Company. I know, not everything is configurable in the components, and that is mostly due to the policy we started with, which was to keep as much configuration in the styling as possible, so we can keep consistency in between components in the applications. But there are different ways to achieve consistency and still keep configurability on a level that developers will be happy to use the API. Both sides have their benefits: smaller API is less complex than one which has plenty of configurations, even if those are color values, on the other hand it is impossible to change its visuals. Some of you may think the API is crap because we don’t provide enough customization, or access to certain elements of the component. We do feel and understand your pain, and we will try to come over it and compensate you in the future.


When the developer starts using a component, he/she expects the component to do what it is meant for. A Button is expected to be clickable, a text input to accept text editing gestures, a list item to provide content layouting functionality when used in views and a header to display a title and some other vital functionality for the application. If a component can cooperate with another one when placed side by side, without the developer doing anything, that is the cherry on the cake. But that’s where the problem starts: a component which must take into account its surroundings and change adapts its behavior creates confusion. A much cleaner approach is to let the developer do this rather than the components themselves, but components should provide connectors and enablers so these interactions can be achieved. Yes, application developers will have to do more, but now they will be in control.

Context Properties as Singletons

Context properties are nice when an application wants to expose a model or other logic to its QML UI layer. Those are pretty simple to implement, however also provide unreadable code for those who read the two worlds (QML and C++ or other non-QML code) separately. The problem gets even worse when these context properties are representing singletons. QML has the notion of singletons but those were not suitable for the functionality we needed for localization (i18n) theming and grid units. The quickest decision was to provide them as context properties, so whenever the locale, system theme or the screen’s grid unit changes during the application’s lifetime, these will be automatically updated, so when used in bindings, those will be automatically re-evaluated. However these context properties cannot be used in shared Javascript libraries. And our measurements had proven that importing a module which contains and uses code-behind implementation javascript libraries takes almost 3 times longer than one which has shared libraries. In addition, now when convergence brings the multi-monitor feature to Ubuntu, each monitor can have a different grid unit size, which means the global units context property singleton is not usable in an application which uses multiple windows. So we must get rid of these kinds of interpretations of the singletons and provide proper ones which are naturally supported by QML.

Complex Theming

Now this is one of the biggest problems. The theming went through a complete evolution: from CSS-like styling to a complete QML-based declarative styling, and then to sub-theming, so each application can use multiple themes at the same time. The performance increased dramatically when we dropped the first version in favor of the declarative one, but it is still slower when compared to a component which implements its visuals on top of a template that provides the logic (see QtQuick Controls second generation).


Oh, yes. All above are contributing to the slow performance of the components, which results in bad performance in applications. Styling is still a bottleneck. We’ve ported some components from QML to C++ to gain some speed in both loading and UI response time, however we have still components entirely written in QML and Javascript, and those are clearly performance eaters. And these monsters are catching your eyes, because they are used the most: AdaptivePageLayout turned to be the most loved component due to its support for the converged application development, but there are the text inputs (TextField and TextArea) which are again components taking too long to instantiate. We have to make them performant, and the only solution is to make them in C++. Of course, C++ is not the Holy Grail, one can make nasty things there too. But so far, we’ve managed to get the components we’ve ported to C++ to behave really well and even provided performance gain to the components derived from them. There was a reason why BlackBerry made its toolkit in C++ and exposed it to QML...

The Plan

So we came up with a plan. And the plan includes you. The plan needs you to succeed, it won’t work without you.

First we thought that we can introduce the new features and slowly turn all the components into performant ones. But then came the DPR support, which despite the fact that from Qt 5.7 onwards it will support floating point value, QWidget based apps will still be broken, as those only support integer sizes. This can be handled behind the scenes, however apps with multiple windows must support different grid unit/DPR sizes when those windows are laid out on different screens. This means that we must do something about the way we handle the grid units, and that, unfortunately, cannot be done without an API break.

But then, if we break it, let’s do it properly! This leads us to really go for the second generation if the UI toolkit, which we were already dreaming of for about a year. This means breaking the backwards compatibility in some APIs. However, whenever is possible, we will keep the interface compatible, but that may not apply to component inheritance.

API design

We will start sharing all API designs with you, so you can contribute! We don’t have a clear plan yet, but we could introduce a “labs” module where the API can be tried out for each component before it lands to the stable module. We must find a way to share the API documents with you so you can comment and request interface changes/additions. (So later you can blame yourself for the mistakes :) ) The policy will be the same, an API once released cannot be revoked, only deprecated. By introducing the labs module, we could give a few weeks or months of time for you to try it out, and provide fixes/comments. Of course, components which were already designed will keep the API but will be exposed for additional requests. And also, we will try to minimize the API to the use cases we have.


When it comes to component implementation we will follow the template+UI layer design, so components will be implemented on top of templates. If your application requires different layout, you will be free to implement it yourself using the template. Therefore we can say that we will have two API layers: the template layer APIs and the UI layer APIs, this last bringing additional properties to the component customizing the look and feel of the component itself, without modifying the logic of the component (i.e. colors, borders, transitions). Both layers will be treated with the same stability promise.

In addition, the theming will still be available, but will not contain anything else but the palette, and the font of the theme. We don’t know yet how will this be available to you, either through a component property of attached properties, we have to benchmark both solutions and see which one is more reliable. Both solutions have their pros and cons, let’s see which one will be the winner.

When Do We Start?

As soon as possible! First we need to open a repository and provide the skeleton for it, and then move the former singletons so we have a clear API for them. Then we need to get the components one by one from the 1.x into the new base, and revisit each component’s API with you all. We will let you know when the trunk is available so you can start playing with it.

When Will It Be Available?

The journey will be a bit longer as we must keep UI Toolkit 1.3 up to date and stable, and in parallel provide features to 2.0. The expectation is that by the end of October we should have a few components in the labs module so those can be tested. We expect to have components appearing in the labs written in C++, so no QML first then move to C++ approach anymore, as the idea is once the component API is seen to be stable enough, we move that to the released package without any effort. Also, as all the major version changes used to be, this version will not be backwards compatible nor usable with 1.x versions, meaning that your QML application would not be able to import 1.x and 2.0 same time.

Shouldn’t We Take The Next Generation of QtQuick Controls as base?

That is a good point, and we’ve been considering that option too. However some of our components’ behavior is so different that it may make sense to simply follow a different path rather than take those as base. But we promise we will consider it as an option. We’ve had a discussion back in last December when we talked about the QtQuick Controls blending in with UI Toolkit, see it here.

Final words

It will be a long journey, a tough one, but finally it will be properly open. Lots of IRC discussions, hangouts, videos, labs works… It’ll be fun! I cannot promise pizza, or beer for you guys, but I promise it'll be hell of a good ride!


Read more
Didier Roche

A quick note reminding you to submit your feedback to the IoT Developer Survey 2016!

The survey is organized by the Eclipse IoT Working Group, IEEE IoT Initiative and the AGILE-IoT H2020 Research Project. Your input will help in understanding the IoT community requirements on software and related tools and to develop resources to more effectively help developers working on the Internet of Things.

This will help as well driving our snappy Ubuntu Core IoT experience, in parternship with those great open source projects!

The deadline to participate is March 25, 2016.

Read more
Zoltán Balogh

SDK Planning for 16.10

On your mark!

We have a clear commitment for the upcoming cycle: We will make it faster! One might ask what exactly we want to make faster and how much faster? From the point of SDK the most important place for performance improvements are the applications and all the consumers of the UI Toolkit. So we will make the applications start up faster, respond faster, use less memory and less power. The starting point for this is to profile and refactor some of the components we know could use some boosting. We will migrate the following components from QML to C++:

  • AdaptivePageLayout

  • Page  

  • Picker

  • DateTimePicker

  • TextField

  • TextArea

In addition to improving the components we will check out the most critical core applications and consult with their developers on how to get the most out of the UITK. We all know how easy it is to create and develop apps in QML, but when it comes to performance, every millisecond matters.

Closing the feature gaps

The groundwork for convergence in the UI Toolkit was successfully put in place but it is not complete yet. We have a few more components to implement and hand over to application developers:

  • header subtitle  

  • keyboard control for the header

  • toolbar scrolling

  • exclusive group

  • radio buttons  

  • popup window

  • context menus  

  • new dialog component  

  • context menu

  • application menu

These components will land as part of Ubuntu.Components 1.3.

APIs and Frameworks

Frameworks and framework versions are not the easiest part of the application development story, to put it mildly.  It is clear that we must have a framework definition that specifies the APIs (platform package, name, import version) that are supported on that particular device and each released framework must have a public definition of the APIs it supports.  
The most fundamental requirements for the API and framework control are:

  • Each platform module that provides application or platform development APIs must have an API definition and an API change tracker.

  • Each platform module that provides an API must have a version number bumping mechanism when it changes its API.

  • Each platform module that provides an API must have a blocking mechanism for API deprecation to prevent API breakage.

  • For application developers it must be trivial to learn what version of each QML module is available in a framework version and what QML import they can use.

  • For application developers there must be an API scanner that checks if the application is using only supported APIs; maybe that tool could help the developer figure out what minimum framework is required by the app.

In the following development cycles we are going to implement and release an API tracker and framework management system to address all these (and many more) related problems.

In short, we will have a simple and consistent framework management solution that will be almost transparent for application developers.

UITK v2.0

Even if the v1.3 of the UI Toolkit still receives new APIs and fixes we better start working on the next major release. It is still way too early to talk about detailed plans, but we already know that for example the multi-screen DPR support will land on 2.0. Other than that this work is still in the brainstorming and planning phase. Stay tuned and expect a blog post about this topic from Zsombor. All in all, now is the  time to step forward and join the discussion!

Development Tools and IDE

In the last few months we have changed a lot around the development tools and the IDE. Finally the IDE is decoupled from the system Qt packages, so we can offer a consistent developer experience regardless of what Ubuntu release the SDK is installed on. This compact and confined packaging gives us more freedom and  flexibility, plus finally we can be as close to the upstream QtCreator and Qt as possible.
The next steps will be to improve the application build process and the app runtime testing. We are prototyping a new builder and runtime container that is based on LXD. It will be much faster, lighter and more reliable than the present schroot based builder. As a bonus we can move the app and scope runtime from the host desktop to the LXD container. It means that developers can see their apps and scopes in a native Unity8 shell in a container without the overhead of the full system emulator.
In the following weeks we will be releasing the Pocket PC edition of the IDE and we will add more and more Snappy support to our tools.

Integration and releases

We will keep up the pace we have set in the last cycle. The goal is to push out a new UI Toolkit release twice a month. Each release takes about a week to be validated. Releasing a new Toolkit is a complex process. We need to make sure that all the visual changes are inline with the design guidelines and we need to run thousands of functional tests (automatic, thanks to autopilot) and check if the new Toolkit blends in with the whole system. Just recently we have added a new feature to our CI. Each merge request can be tested from a simple installable click package. So if somebody wants to follow the UITK development it can be safely done without messing up the system.

Keeping it all open

Even under all the pressure to deliver the UI Toolkit and the SDK we will not forget that what we do is not only open source software but we do it in an open way. It is obvious that the UI Toolkit and the IDE projects are all open, but we need to ensure that how we work is open, too. We will keep publishing technical blog posts and videocasts about what is going on in the SDK workshops. We welcome all contributions to our projects and we are going to participate in various events to hear developers and to share information.


Read more
David Callé

Last weekend for the Scopes Showdown!

Almost six weeks since the start of the Showdown and we have been overly impressed by the number of questions we have received and hope we have been able to provide the right support for you to complete your entry.

Here is a kind reminder that the deadline to submit your entry is monday February 29th.

If you are still hesitant to enter, have a look at the following resources to get you started with a JavaScript scope:

For other languages (C++ and Go), you can browse our list of tutorials and guides.

Happy hacking !

Read more