Canonical Voices

Posts tagged with 'article'


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
Tim Peeters

PageHeader tutorial

The new header property

This is a tutorial on how to use the new PageHeader component. So far, we had one header per application, implemented in the MainView, and configurable for each page using the Page.head property (which is an instance of PageHeadConfiguration). We deprecated that approach, and added the Page.header property, which can be set to be any Item so that each page has its own header instance. When it is set, two things happen:

  1. The (deprecated) application header is disabled and any configuration that may be set using the old Page.head property is ignored,

  2. The Page.header item is parented to the page.

Because the header is parented to the page, inside the header you can refer to its parent, and other items inside the page can anchor to the header.


Example 1

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    Page {
        id: page
        header: Rectangle {
            width: parent.width
            Label {
                anchors.centerIn: parent
                text: "Title"
                color: "white"
        Rectangle {
            anchors {
                left: parent.left
                right: parent.right
                bottom: parent.bottom
                top: page.header.bottom
            Label {
                anchors.centerIn: parent
                text: "Hello, world!"
                color: "white"

Use PageHeader for an Ubuntu header

In order to get a header that looks like an Ubuntu header, use the PageHeader component. This component provides properties to set the title and actions in the header and shows them the way you are used to in Ubuntu apps. Below I will show how to customize the header styling, but first an example that uses the default visuals:

Example 2

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    Page {
        header: PageHeader {
            title: "Ubuntu header"
            leadingActionBar.actions: [
                Action {
                    iconName: "contact"
                    text: "Navigation 1"
                Action {
                    iconName: "calendar"
                    text: "Navigation 2"
            trailingActionBar.actions: [
                Action {
                    iconName: "settings"
                    text: "First"
                Action {
                    iconName: "info"
                    text: "Second"
                Action {
                    iconName: "search"
                    text: "Third"

The leadingActionBar and trailingActionBar are instances of ActionBar, and can thus be configured in the same way any action bar can be configured. The default settings for the leading action bar configures the number of slots as 1, sets the overflow icon to "navigation-menu", and the default value for actions is navigationActions, which is a property of the PageHeader set by the PageStack or AdaptivePageLayout to show a back button when needed. If leadingActionBar.actions is explicitly defined as in the example above, the back button added by a PageStack or AdaptivePageLayout is ignored. The trailing action bar automatically updates its number of slots depending on the space available for showing actions. On a phone it will show 3 actions by default, but on a tablet or desktop more. When actions.length > numberOfSlots for the leading or trailing action bar, an overflow button will automatically be shown that shows the other actions when tapped.

Automatic show/hide behavior

The examples above show a static header where the page contents is anchored to the bottom of the header. When the page contains a Flickable or ListView, this can be linked to the header so that it automatically moves with the flickable:

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    Page {
        header: PageHeader {
            title: "Ubuntu header"
            flickable: listView
            trailingActionBar.actions: [
                Action {
                    iconName: "info"
                    text: "Information"
        ListView {
            id: listView
            anchors.fill: parent
            model: 20
            delegate: ListItem {
                Label {
                    anchors.centerIn: parent
                    text: "Item " + index

When PageHeader.flickable is set, the header automatically scrolls with the flickable, and the topMargin of the Flickable or ListView is set to leave enough space for the header, so the flickable can fill the page. Besides using the flickable to scroll the header in and out of the view, the property can be set to show or hide the header. The PageHeader will automatically become more slim on a phone in landscape orientation to make better use of the limited vertical screen space.

Extending the header

Some applications require more functionality in the header besides the actions in the leading and trailing action bars. For this, we have the extension property which can be any Item that will be attached at the bottom of the header. For changing what is 'inside' the header, there is the contents property which will replace the default title label. The following example shows how to use the extension and contents properties to implement search mode and edit mode that can be switched between by clicking the action buttons in the default header:

Example 4a

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    Page {
        id: page
        header: standardHeader
        Label {
            anchors {
                horizontalCenter: parent.horizontalCenter
                top: page.header.bottom
            text: "Use the icons in the header."
            visible: standardHeader.visible
        PageHeader {
            id: standardHeader
            visible: page.header === standardHeader
            title: "Default title"
            trailingActionBar.actions: [
                Action {
                    iconName: "search"
                    text: "Search"
                    onTriggered: page.header = searchHeader
                Action {
                    iconName: "edit"
                    text: "Edit"
                    onTriggered: page.header = editHeader
        PageHeader {
            id: searchHeader
            visible: page.header === searchHeader
            leadingActionBar.actions: [
                Action {
                    iconName: "back"
                    text: "Back"
                    onTriggered: page.header = standardHeader
            contents: TextField {
                anchors {
                    left: parent.left
                    right: parent.right
                    verticalCenter: parent.verticalCenter
                placeholderText: "Search..."
        PageHeader {
            id: editHeader
            visible: page.header === editHeader
            property Component delegate: Component {
                AbstractButton {
                    id: button
                    action: modelData
                    width: label.width +
                    height: parent.height
                    Rectangle {
                        color: UbuntuColors.slate
                        opacity: 0.1
                        anchors.fill: parent
                        visible: button.pressed
                    Label {
                        anchors.centerIn: parent
                        id: label
                        text: action.text
                        font.weight: text === "Confirm"
                                     ? Font.Normal
                                     : Font.Light
            leadingActionBar {
                anchors.leftMargin: 0
                actions: Action {
                    text: "Cancel"
                    iconName: "close"
                    onTriggered: page.header = standardHeader
                delegate: editHeader.delegate
            trailingActionBar {
                anchors.rightMargin: 0
                actions: Action {
                    text: "Confirm"
                    iconName: "tick"
                    onTriggered: page.header = standardHeader
                delegate: editHeader.delegate
            extension: Toolbar {
                anchors {
                    left: parent.left
                    right: parent.right
                    bottom: parent.bottom
                trailingActionBar.actions: [
                    Action { iconName: "bookmark-new" },
                    Action { iconName: "add" },
                    Action { iconName: "edit-select-all" },
                    Action { iconName: "edit-copy" },
                    Action { iconName: "select" }
                leadingActionBar.actions: Action {
                    iconName: "delete"
                    text: "delete"
                    onTriggered: print("Delete action triggered")

Customize the looks

Now that we covered the basic functionality of the page header, let's see how we can customize the visuals. That can be done by creating a theme for your app that overrides the PageHeaderStyle of the Ambiance theme, or by using StyleHints inside the PageHeader. To change the looks of the header for every page in your application, it is recommended to create a custom theme, but the example below shows how to use StyleHints to change the properties of PageHeaderStyle for a single PageHeader instance:

Example 5

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    Page {
        header: PageHeader {
            title: "Ubuntu header"
            StyleHints {
                foregroundColor: "white"
                dividerColor: UbuntuColors.ash
            trailingActionBar {
                actions: [
                    Action {
                        iconName: "info"
                        text: "Information"
                    Action {
                        iconName: "settings"
                        text: "Settings"

If the header needs to be customized even further, use the contents property, as is demonstrated in the example above for the search mode, or use any Item for Page.header, as was shown in the first example. For a fully custom header that will still show and hide automatically when the user scrolls in the page, use the Header component which is the parent component of PageHeader, and set its flickable property.

That’s all. I am looking forward to see what you will do with the new and often-requested flexibility of the new header in the Ubuntu UI Toolkit.

Read more
liam zheng

魅族Ubuntu版手机PRO 5已亮相2016 MWC,可在魅族官方网站开始接受预定,售价为369.99美元(全球包邮)。


今天是2016 MWC的第一天,Ubuntu在3号厅3J30展台为大家带来特别的一次展示,手机预装展示版Ubuntu手机系统,正式发售时会预装有下一个OTA系统更新。


魅族PRO 5 Ubuntu版手机可通过魅族官网预定并在Canonical新合作伙伴京东全球在线购物网站上进行购买。京东是中国最大的在线购物平台,为全球消费者更快、更方便的购物体验。届时,魅族PRO 5 Ubuntu版手机将通过京东全球购平台销售和快递。


时隔一年,魅族PRO 5 Ubuntu版手机自魅族和Canonical合作推出的第二款设备,也是第五款Ubuntu手机。魅族科技的副总裁李楠表示:“魅族和Canonical有很多有趣的计划,期待在未来能有更深入的合作”。




Read more
Robin Winslow

There has been a growing movement to get all websites to use SSL connections where possible. Nowadays, Google even uses it as a criterion for ranking websites.

I've written before about how to host an HTTPS website for free with StartSSL and OpenShift. However, StartSSL is very hard to use and provides very basic certificates, and setting up a website on OpenShift is a fairly technical undertaking.

There now exists a much simpler way to setup an HTTPS website with CloudFlare and GitHub Pages. This only works for static sites.

If your site is more complicated and needs a database or dynamic functionality, or you need an SHA-1 fallback certificate (explained below) then look at my other post about the OpenShift solution. However, if a static site works for you, read on.

GitHub Pages

As most developers will be aware by now, GitHub offer a fantastic free static website hosting solution in GitHub Pages.

All you have to do is put your HTML files in the gh-pages branch of one of your repositories and they will be served as a website at {username}{project-name}.

GitHub pages minimal files

And all files are passed through the Jekyll parser first, so if you want to split up your HTML into templates you can. And if you don't want to craft your site by hand, you can use the Automatic Page Generator.

automatic page generator themes

Websites on also support HTTPS, so you can serve your site up at https://{username}{project-name} if you want.

mytestwebsite GitHub pages

GitHub Pages also support custom domains (still for free). Just add a CNAME file to the repository with your domain name in it - e.g. - and then go and setup the DNS CNAME to point to {username}

mytestwebsite GitHub pages files

The only thing you can't do directly with GitHub Pages is offer HTTPS on your custom domain - e.g. This is where CloudFlare comes in.


CloudFlare offer a really quite impressive free DNS and CDN service. This free service includes some really impressive offerings, the first three of which are especially helpful for our current HTTPS mission:

The most important downside to CloudFlare's free tier SSL is that it doesn't include the fall-back to legacy SHA-1 for older browsers. This means that the most out-of-date (and therefore probably the poorest) 1.5% of global citizens won't be able to access your site without upgrading their browser. If this is important to you, either find a different HTTPS solution or upgrade to a paid CloudFlare account.

Setting up HTTPS

Because CloudFlare are a CDN and a DNS host, they can do the HTTPS negotiation for you. They've taken advantage of this to provide you with a free HTTPS certificate to encrypt communication between your users and their cached site.

First simply setup your DNS with CloudFlare to point to {username}, and allow CloudFlare to cache the site.

mytestwebsite CloudFlare DNS setup

Between CloudFlare and your host the connection doesn't have to be encrypted, but I would certainly suggest that it still should be. But crucially for us, this encrypted connection doesn't actually need a valid HTTPS certificate. To enable this we should select the "Full" (rather than "Flexible" or "Strict") option.

CloudFlare full SSL encryption

Et voilà! You now have an encrypted custom domain in front of GitHub Pages completely for free!

mytestwebsite with a secure domain

Ensuring all visitors use HTTPS

To make our site properly secure, we need to ensure all users are sent to the HTTPS site ( instead of the HTTP one (

Setting up a page rule

The first step to get visitors to use HTTPS is to send a 301 redirect from to

Although this is not supported with GitHub Pages, it can be achieved with CloudFlare page rules.

Just add a page rule for http://*{}/* (e.g. http://**) and turn on "Always use HTTPS":

CloudFlare always use HTTPS page rule

Now we can check that our domain is redirecting users to HTTPS by inspecting the headers:

$ curl -I
HTTP/1.1 301 Moved Permanently

HTTP Strict Transport Security (HSTS)

To protect our users from man-in-the-middle attacks, we should also turn on HSTS with CloudFlare (still for free). Note that this can cause problems if you're ever planning on removing HTTPS from your site.

If you're using a subdomain (e.g., remember to enable "Apply HSTS policy to subdomains".

CloudFlare: HSTS setting

This will tell modern browsers to always use the HTTPS protocol for this domain.

$ curl -I
HTTP/1.1 200 OK
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff

It can take several weeks for your domain to make it into the Chromium HSTS preload list. You can check if it's in there, or add it again, by visiting chrome://net-internals/#hsts in a Chrome or Chromium browser and looking for the static_sts_domain setting.

That's it!

You now have an incredibly quick and easy way to put a fully secure website online in minutes, totally for free! (Apart from the domain name).

(Also posted on my personal blog - which uses the free CloudFlare plan.)

Read more
Robin Winslow

I often find myself wanting to play around with a tiny Python web application with native Python without installing any extra modules - the Python developer's equivalent of creating an index.html and opening it in the browser just to play around with markup.

For example, today I found myself wanting to inspect how the Google API Client Library for Python handles requests, and a simple application server was all I needed.

In these situations, the following minimal WSGI application, using the built-in wsgiref library is just the ticket:

from wsgiref.simple_server import make_server

def application(env, start_response):
    A basic WSGI application

    http_status = '200 OK'
    response_headers = [('Content-Type', 'text/html')]
    response_text = "Hello World"

    start_response(http_status, response_headers)
    return [response_text]

if __name__ == "__main__":
    make_server('', 8000, application).serve_forever()

Put this in a file - e.g. - and run it with:

(I've also saved this as a Gist).

This provides you with a very raw way of parsing HTTP requests. All the HTTP variables come in as items in the env dictionary:

def application(env, start_response):
    # To get the requested path
    # (the /index.html in
    path = env['PATH_INFO']
    # To get any query parameters
    # (the foo=bar in
    qs = env['QUERY_STRING']

What I often do from here is use ipdb to inspect incoming requests, or directly manipulate the response headers or content.

Alternatively, if you're looking for something slightly more full-featured (but still very lightweight) try Flask.

(Also posted over on

Read more
liam zheng


在之前的培训教程"在Ubuntu OS上创建一个dianping Scope (Qt JSON)"中,介绍了如何使用C++来在Ubuntu平台上开发一个Scope;在文章"使用golang来设计Ubuntu Scope"里也展示了如何使用go语言来在Ubuntu上开发一个Scope。今天将展示如何利用Javascript语言来开发一个Scope。这对于网页开发的开发者来说,无疑是一个好消息,不需要学习另外一种语言就可以轻松地开发一个Scope。更多关于Scope开发的知识可以在这里获得。


首先,必须强调的是Javascrip支持Scope的开发始于Ubuntu 15.04(vivid)系统及以后的版本。在开发之前,开发者必须按照文章"Ubuntu SDK 安装"安装好的SDK。同时,必须做如下的JS Scope开发工具的安装:

$ sudo apt install unity-js-scopes-dev
$ unity-js-scopes-tool setup

在这里必须注意的是,必须在安装完Ubuntu SDK后才可以执行上面的安装,并在SDK的安装中chroots必须安装完整。经过上面的安装,基本上已经完成了所有的工具的安装。


二、JS Scope开发文档

所有的开发离不开所需要的技术文档,JS Scope的开发文档的地址可以在early build找到,当然也可以通过安装unity-js-scopes-doc包来得到帮助。



A、Webservice API:



{"error":0,"status":"success","date":"2016-01-18","results":[{"currentCity":"北京","pm25":"13","index":[{"title":"穿衣","zs":"寒冷","tipt":"穿衣指数","des":"天气寒冷,建议着厚羽绒服、毛皮大衣加厚毛衣等隆冬服装。年老体弱者尤其要注意保暖防冻。"},{"title":"洗车","zs":"较适宜","tipt":"洗车指数","des":"较适宜洗车,未来一天无雨,风力较小,擦洗一新的汽车至少能保持一天。"},{"title":"旅游","zs":"一般","tipt":"旅游指数","des":"天气较好,温度稍低,而且风稍大,让您感觉有些冷,会对外出有一定影响,外出注意防风保暖。"},{"title":"感冒","zs":"极易发","tipt":"感冒指数","des":"天气寒冷,昼夜温差极大且空气湿度较大,易发生感冒,请注意适当增减衣服,加强自我防护避免感冒。"},{"title":"运动","zs":"较不宜","tipt":"运动指数","des":"天气较好,但考虑天气寒冷,风力较强,推荐您进行室内运动,若在户外运动请注意保暖并做好准备活动。"},{"title":"紫外线强度","zs":"弱","tipt":"紫外线强度指数","des":"紫外线强度较弱,建议出门前涂擦SPF在12-15之间、PA+的防晒护肤品。"}],"weather_data":[{"date":"周一 01月18日 (实时:-8℃)","dayPictureUrl":"","nightPictureUrl":"","weather":"晴","wind":"北风3-4级","temperature":"-4 ~ -11℃"},{"date":"周二","dayPictureUrl":"","nightPictureUrl":"","weather":"晴转多云","wind":"微风","temperature":"-1 ~ -8℃"},{"date":"周三","dayPictureUrl":"","nightPictureUrl":"","weather":"多云转阴","wind":"微风","temperature":"0 ~ -7℃"},{"date":"周四","dayPictureUrl":"","nightPictureUrl":"","weather":"阴转多云","wind":"微风","temperature":"-3 ~ -6℃"}]}]}




在这一节中,来练习创建一个JS Scope,可以利用在Ubuntu SDK中所提供的template来轻松地创建一个Scope。首先,打开SDK,选择"New File or Project":


显示如下,基本上没有什么特别的东西。它在默认的情况下显示的是一个天气的Scope,但可以在它里面输入一些感兴趣的城市的名称来得到当前城市的天气情况。也可以选择SDK屏幕做下角的Desktop或Ubuntu Desktop SDK kit来在Desktop的环境下运行。当在手机上运行时,必须选择Ubuntu SDK for armhf来运行:




liuxg@liuxg:~/release/chinaweatherjs$ tree
├── chinaweatherjs.apparmor
├── CMakeLists.txt
├── CMakeLists.txt.user
├── po
│   ├── chinaweatherjs.pot
│   ├── CMakeLists.txt
│   ├──
│   ├──
│   └──
└── src
    ├── chinaweatherjs.js
    ├── CMakeLists.txt
    ├── data
    │   ├──
    │   ├──
    │   ├── icon.png
    │   └── logo.png
    ├── etc
    └── node_modules
        ├── last-build-arch.txt
        └── unity-js-scopes
            ├── bin
            │   └── unity-js-scopes-launcher
            ├── index.js
            ├── lib
            │   └── scope-core.js
            └── unity_js_scopes_bindings.node

8 directories, 20 files




细心的开发者可能已经注意到一个叫做node_modules的目录,JS Scope使用的框架就是npm + Scope,可以很方便地使用unity-js-scopes-tool来加入所需要的npm包到Scope项目中去,运行的命令如下:

$ unity-js-scopes-tool install <path/to/project/src/node_modules> <npm package>





Javascript Scope的基本架构


  • 导入 Javascript Scope模块到你的代码中
  • 设置你的Scope的runtime上下文


var scopes = require('unity-js-scopes')
scopes.self.initialize({}, {});

一旦被导入,unity-js-scopes核心模块即是和Scope runtime交互的入口点,runtime可设置Scope,和Dash进行交互及显示用户在Scope交互所生产的结果等。


        get: function() {
            if (! self) {
                self = new Scope();
            return self;

除了定义一些Scope在运行时的一下runtime元素以外,runtime上下文还允许检查当前Scope的设置及接受scope runtime环境变化时所生产的变化等。


Runtime 元素


一旦Scope和runtime建立起连接并被用户所启动,scope runtime将发送来所有的由用户所产生的动作。最终这些动作将被发送到Scope在Initialize过程中所定义的API函数中。


  • run: 当一个scope准备运行时,这个回调函数将被调用.
  • start: 当一个scope准备启动时,这个函数将被调用
  • stop: 当一个scope准备停止时,这个函数将被调用
  • search: 当用户请求一个搜索时,这个函数将被调用.runtime将将提供所有的关于搜索所需要的信息给这个函数的调用.开发者的任务就是通过和runtime的交互把所有可能的结果push给runttime.你也可以控制如何显示这些结果
  • preview: 显示一个在上面search中显示结果的preview.runtime将提供关于这个preview所需要的所有的信息


var scopes = require('unity-js-scopes')
scopes.self.initialize({}, {
    run: function() {
    start: function(scope_id) {
        console.log('Starting scope id: ' + scope_id + ', ' + scopes.self.scope_config)
    search: function(canned_query, metadata) {
        return null
    preview: function(result, metadata) {
        return null

对于每一个scope runtime的回调函数来说,它相应于一个用户的交互。scope runtime希望scope发送回一个描述各个关键交互所需要的对象。


SearchQuery object可以定义一个run回调函数。当搜索发生时,该函数将被调用。同时它也可以定义一个cancel的回调函数,当一个搜索被停止时,该函数将被调用。

Scope runtime同时也传入一个叫做SearchReply的object,这个object可以被用来push一些结果到scope runtime。

上面的这种交互模式是贯穿了整个scope及scope rumtime设计的核心交互模式。



上面讲到的一个最核心的搜索交互就是scope可以把所需要的结果推送到scope runtime。这些结果是通过SearchReply来完成推送的,这个函数希望一个叫做CategorisedResult类型的数据被创建,并被推送到scope runtime。这个result对象将让我们的scope来定义诸如title, icon,uri等信息。



var query_host = ""
var weather_path = "/telematics/v3/weather?output=json&ak=DdzwVcsGMoYpeg5xQlAFrXQt&location=" 
var URI = ""; 


                search: function(canned_query, metadata) {
                    return new scopes.lib.SearchQuery(
                                // run
                                function(search_reply) {
                                    var qs = canned_query.query_string();
                                    if (!qs) {
                                        qs = "北京"

                                    console.log("query string: " + qs);

                                    var weather_cb = function(response) {
                                        var res = '';

                                        // Another chunk of data has been recieved, so append it to res
                                        response.on('data', function(chunk) {
                                            res += chunk;

                                        // The whole response has been recieved
                                        response.on('end', function() {
                                            // console.log("res: " + res);

                                            r = JSON.parse(res);

                                            // Let's get the detailed info
                                            var request_date =
                                            console.log("date: " + date);

                                            var city = r.results[0].currentCity;
                                            console.log("city: " + city);

                                            var pm25 = r.results[0].pm25
                                            console.log("pm25: " + pm25)

                                            var category_renderer = new scopes.lib.CategoryRenderer(JSON.stringify(WEATHER_TEMPLATE));
                                            var category = search_reply.register_category("Chineweather", city, "", category_renderer);

                                            try {
                                                r = JSON.parse(res);
                                                var length = r.results[0].weather_data.length
                                                console.log("length: " + length)

                                                for (var i = 0; i < length; i++) {
                                                    var categorised_result = new scopes.lib.CategorisedResult(category);

                                                    var date = r.results[0].weather_data[i].date
                                                    console.log("date: "+  date);

                                                    var dayPictureUrl = r.results[0].weather_data[i].dayPictureUrl;
                                                    console.log("dayPictureUrl: " + dayPictureUrl);

                                                    var nightPictureUrl = r.results[0].weather_data[i].nightPictureUrl;
                                                    console.log("nightPictureUrl: " + nightPictureUrl);

                                                    var weather = r.results[0].weather_data[i].weather;
                                                    console.log("weather: " + weather);

                                                    var wind = r.results[0].weather_data[i].wind;
                                                    console.log("wind: " + wind);

                                                    var temperature = r.results[0].weather_data[i].temperature;
                                                    console.log("temperature: " + temperature);

                                                    categorised_result.set("weather", weather);
                                                    categorised_result.set("wind", wind);
                                                    categorised_result.set("temperature", temperature);

                                                    categorised_result.set_title("白天: " + date );
                                                    categorised_result.set("subtitle", weather);

                                                    categorised_result.set_title("夜晚: " + date );


                                                // We are done, call finished() on our search_reply
//                                              search_reply.finished();
                                            catch(e) {
                                                // Forecast not available
                                                console.log("Forecast for '" + qs + "' is unavailable: " + e)

                                    console.log("request string: " + query_host + weather_path + qs);

                                    http.request({host: query_host, path: weather_path + encode_utf8(qs)}, weather_cb).end();

                                // cancelled
                                function() {



一旦搜索结果被推送到scope runtime并被显示,用户可以点击显示的结果并请求一个关于该结果的preview.Scope runtime将通过scope中所定义的preview回调来显示所需要的结果.


就像上面对search所描述的那样,scope runtime希望的scope返回一个PreViewQuery的对象来作为一个交互的桥梁。这个对象必须指定一个run及一个cancel的函数.这两个函数和上面介绍的search中的语义是一样的。这里不再累述。


对Preview来说,有两个最重要的元素:column layout及Preview Widgets。就像它们的名字所描述的那样,column layout元素是用来定义Preview页面中Preview Component的layout的。Preview Widget是用来在Preview页面中组成页面的。



  preview: function(result, action_metadata) {
                    return new scopes.lib.PreviewQuery(
                                // run
                                function(preview_reply) {
                                    var layout1col = new scopes.lib.ColumnLayout(1);
                                    var layout2col = new scopes.lib.ColumnLayout(2);
                                    var layout3col = new scopes.lib.ColumnLayout(3);
                                    layout1col.add_column(["imageId", "headerId", "temperatureId", "windId"]);

                                    layout2col.add_column(["headerId", "temperatureId", "windId"]);

                                    layout3col.add_column(["headerId", "temperatureId", "windId"]);

                                    preview_reply.register_layout([layout1col, layout2col, layout3col]);

                                    var header = new scopes.lib.PreviewWidget("headerId", "header");
                                    header.add_attribute_mapping("title", "title");
                                    header.add_attribute_mapping("subtitle", "subtitle");

                                    var image = new scopes.lib.PreviewWidget("imageId", "image");
                                    image.add_attribute_mapping("source", "art");

                                    var temperature = new scopes.lib.PreviewWidget("temperatureId", "text");
                                    temperature.add_attribute_mapping("text", "temperature");

                                    var wind = new scopes.lib.PreviewWidget("windId", "text");
                                    wind.add_attribute_mapping("text", "wind");

                                    preview_reply.push([image, header, temperature, wind ]);
                                // cancelled
                                function() {




Read more
David Callé

Today we announce the launch of our second Ubuntu Scopes Showdown! We are excited to bring you yet another engaging developer competition, where the Ubuntu app developer community brings innovative and interesting new experiences for Ubuntu on mobile devices.

Scopes in Javascript and Go were introduced recently and are the hot topic of this competition!

Contestants will have six weeks to build and publish their Unity8 scopes to the store using the Ubuntu SDK and Scopes API (JavaScript, Go or C++), starting Monday January 18th.

A great number of exciting prizes are up for grabs: a System76 Meerkat computer, BQ E5 Ubuntu phones, Steam Controllers, Steam Link, Raspberry Pi 2 and convergence packs for Ubuntu phones!

Find out more details on how to enter the competition. Good luck and get developing! We look forward to seeing your scopes on our Ubuntu homescreens!

Read more
April Wang


Ubuntu的展台除了展示目前已上市欧洲的两款现有Ubuntu手机机型,还有核心的三大亮点部分组成,首先展出了即将推出的一个重大手机功能性更新 - 让Ubuntu手机轻松变身个人电脑的Convergence技术,此外亮相现场的还有目前与中国移动合作研发的一款手机展示,以及Ubuntu系统在智能物联网硬件芯片上应用的展示。 

从今年初开始Ubuntu陆续有三款机型上市欧洲,首款BQ E4.5机型还在2015年的MWC大会上有展出,此后魅族MX4和BQ E5也陆续上架欧洲。 除了欧洲市场,今年Ubuntu的BQ版手机还在印度, 俄罗斯两国分别进行了销售,让当地的小伙伴们也尝到了鲜。 

在此次中国移动全球合作伙伴大会上,有一项会让现有手机功能极大提升的特征,又被称为Convergence的技术,在现场亮相展出。 它通过蓝牙连接无线鼠标,键盘,HDMI接线连接显示屏,可以将手机内容呈现到屏幕上;这样用户可以将自己的手机作为一台电脑来使用,完成一些很难或根本无法操作的任务,比如在数据表中进行数据统计等等。这是一个移动设备发展的趋势,科能(Canonical)公司早在2013年就提出了讲个人手机转型成个人电脑的设想,并在国外众筹平台提交次项目,虽然项目没还有筹备到目标金额,却依然很明显的证明了整个移动设备和传统个人电脑边界模糊的趋势,以及现存的市场需求。而在这次的大会中,现场的小伙伴们可以亲身体验一下了。目前版本依然处于一个Alpha版本状态, 但是喜欢自己动手“折腾”的小朋友现在就可以通过使用Nexus 4手机或Nexus 7的平板来使用Ubuntu移动产品这一先锋性的技术。

而展台另一面的亮点便是和中国移动合作研发中的一款硬件设备,这款设备上除了Ubuntu特有的常用型Scope,还展现了集合中国移动咪咕平台内容的几款Scope,包括和阅读, 和音乐,以及和彩云服务。除了内容上的亮点,重头戏其实是这款设备上呈现的RCS技术。 RCS英文全名又被称为Rich Communication Services,简单而言这套技术就是可以让手机用户在传统手机短信的基础上可以有更加丰富的信息数据的发送接收, 例如语音对话,视频对话,发送图片,甚至类似阅后即焚的功能。RCS技术其实在国外已经有很多家运营商实现了此功能,中国移动是国内首家开始正式研发RCS的中国运营商,而在此次大会上这款技术首次在一款Ubuntu手机上展示了出来,不能不说这是很重要的一个亮点。 

Ubuntu作为一款开源操作系统除了运行在云,PC,和手机移动设备之外, 在智能物联网的世界其实已经存在有一段时间了。很多早期开发机器人,无人机的先锋都是在使用Ubuntu操作系统。Ubuntu还是开源机器人基金(Open source robotics foundation)的软件平台基础。目前戴尔的Edge Gateway 5000 Series,以及DJI大疆的机载电脑“妙算 Manifold”也都是运行着Ubuntu的系统。这次移动大会现场,大疆的妙算也亮相现场。 

中国移动全球合作伙伴大会历时三天,展示了整个移动硬件,软件,系统, 芯片等等一整套生态线。 科能也有幸通过这次机会给所有参会伙伴们展示了Ubuntu在2015年一年来的进展和未来手机移动开发的方向和在智能物联网行业的长久计划。 


Read more
Benjamin Zeller

In the last couple of weeks, we had to completely rework the packaging for the SDK tools and jump through hoops to bring the same experience to everyone regardless if they are on LTS or the development version of Ubuntu. It was not easy but we finally are ready to hand this beauty to the developer’s hands.

The two new packages are called “ubuntu-sdk-ide” and “ubuntu-sdk-dev” (applause now please).

The official way to get the Ubuntu SDK installed is from now on by using the Ubuntu SDK Team release PPA:

Releasing from the archive with this new way of packaging is sadly not possible yet, in Debian and Ubuntu Qt libraries are installed into a standard location that does not allow installing multiple minor versions next to each other. But since both, the new QtCreator and Ubuntu UI Toolkit, require a more recent version of Qt than the one the last LTS has to offer we had to improvise and ship our own Qt versions. Unfortunately that also blocks us from using the archive as a release path.

If you have the old SDK installed, the default QtCreator from the archive will be replaced with a more recent version. However apt refuses to automatically remove the packages from the archive, so that is something that needs to be done manually, best before the upgrade:

sudo apt-get remove qtcreator qtcreator-plugin*

Next step is to add the ppa and get the package installed.

sudo add-apt-repository ppa:ubuntu-sdk-team/ppa \
    && sudo apt update \
    && sudo apt dist-upgrade \
    && sudo apt install ubuntu-sdk

That was easy, wasn’t it :).

Starting the SDK IDE is just as before, either by running qtcreator or ubuntu-sdk directly and also by running it from the dash. We tried to not break old habits and just reused the old commands.

However, there is something completely new. An automatically registered Kit called the “Ubuntu SDK Desktop Kit”. That kit consists of the most recent UITK and Qt used on the phone images. Which means it offers a way to develop and run apps easily even on an LTS Ubuntu release. Awesome, isn’t it Stuart?

The old qtcreator-plugin-ubuntu package is going to be deprecated and will most likely be removed in one of the next Ubuntu versions. Please make sure to migrate to the new release path to always get the most recent versions.

Read more

As a follow-up to our previous post A Fast Thumbnailer for Ubuntu, we have published a new tutorial to help you make the most of this new SDK feature in your apps.

You will learn how to generate on-demand thumbnails for pictures, video and audio files by simply importing the module in your QML code and slightly tweaking your use of Image components.

Read the tutorial ›

Read more
Thibaut Rouffineau

The Eclipse Foundation has become a new home for a number of IoT projects. For the newcomers in the IoT world it’s always hard to see the forest for the trees in the number of IoT related Eclipse projects. So here is a first blog to get you started with IoT development using Eclipse technology.

The place to start with IoT development is MQTT (Messaging Queuing Telemetry Transport). MQTT is a messaging protocol used to send information between your Things and the Cloud. It’s a bit like the REST API of the IoT world, it’s standardised and supported by most clients, servers and IOT Backend As A Service (BaaS) vendors (AWS IOT, IBM Bluemix, Relayr, Evrything to name a few).

If you’re not familiar with MQTT here is a quick rundown of how it works:

  • MQTT was created for efficient and lightweight message exchanges between Things (embedded devices / sensors).

  • An MQTT client is typically running on the embedded device and sends messages to an MQTT broker located on a server.

  • MQTT messages are made of 2 fields a topic and a message.

  • MQTT clients can send (publish in MQTT linguo) messages on a specific topic. Typically a light in my kitchen would send a message of this type to indicate it’s on:  topic =”Thibaut/Light/Kitchen/Above_sink/pub” message=”on”.

  • MQTT clients can listen (subscribe in MQTT linguo) to messages on a specific topic. Typically a light in my kitchen would subscribe to messages to await for instruction to be turned off by subscribing to the  topic =”Thibaut/Light/Kitchen/Above_sink/sub” and waiting for a message: message=”turn_off”.

  • MQTT brokers listen to incoming messages and retransmit the messages to clients subscribed to a specific topic. In this way it resembles a multicast network.

  • Most MQTT brokers are running in the cloud but increasingly MQTT brokers can be found on IoT gateways in order to do message filtering and create local rules for emergency or privacy reasons. For example a typical local rule in my house would be if a presence sensor in the kitchen sends a message saying that no one is in the kitchen a simple rule would send a message to the light to switch it. Our rules engine would look like: if receive message: topic=”Thibaut/presence_sensor/Kitchen/pub” message =”No presence”  then send message on topic =”Thibaut/Light/Kitchen/Above_sink/sub” with message=”turn_off”

  • BaaS vendors would typically offer a simple rules engine sitting on top of the MQTT broker, even though most developers would probably build their rules within their code. Your choice!

  • To get started Eclipse provides multiple MQTT client under the Paho project

  • To get started with your own broker Eclipse provides an MQTT broker under the Mosquitto project

  • Communication between MQTT client and broker supports different level of authentication from none to using public /private keys through username / password

  • When using a public MQTT broker (like the Eclipse sandbox) your messages will be visible to all people who subscribe to your topics so if you’re going to do anything confidential make sure you have your own MQTT broker (either through a BaaS or build your own on a server).

That’s all there is to know about MQTT! As you can see it’s both simple and powerful which is why it’s been so successful and why so many vendors have implemented it to get everyone started with IoT.
And now is your time to get started!! To help out here’s a quick example on Github that shows you how you can get the Paho Python MQTT running on Ubuntu Core and talking to the Eclipse Foundation MQTT sandbox server. Have a play with it and tell us what you’ve created with it!

Read more
April Wang



全球飞行影像系统开拓者DJI大疆创新发布专为飞行平台设计的嵌入式高性能机载电脑“妙算” Manifold。配合大疆Onboard SDK,妙算提供了便捷易用的全新功能,让开发者释放创造力,打造更加强大的无人机行业应用。

大疆创新战略合作总监Michael Perry表示:“妙算将开启智能飞行平台的全新时代,作为联接地面设备和飞行终端的智能协作中枢,妙算可为复杂的行业应用提供解决方案。我们非常期待开发者通过妙算开发出令人眼前一亮的应用”。

妙算能够广泛扩展第三方传感器,开发者在经纬M 100上可通过妙算连接红外摄像机、气象研究设备以及地理信息采集设备,并可在飞行中实时收集和分析数据。

妙算搭载Canonical公司的Ubuntu操作系统,并支持CUDA, OpenCV以及ROS。配备英伟达Tegra嵌入式处理器,其包含四核ARM Cortex A-15处理器和Kepler架构的图形处理单元,这使得妙算不仅能实现强大的图像处理能力,且能高效地处理并行任务。此外,妙算还可广泛应用于计算机视觉、深度学习等人工智能领域,并提供USB、Ethernet、HDMI等丰富的接口,用于连接传感器、显示屏等多种扩展设备。

Canonical公司智能设备及全球战略合作副总裁Mark Murphy说:“我们非常高兴能与DJI大疆创新合作,Canonical和大疆创新分享同样的愿景,致力于推动科技进步,为开发者铺平前进的道路”。

搭载Ubuntu 14.04 LTS版本的妙算将于今日在大疆创新官方商城全球同步预售,中国大陆地区该产品售价为人民币2999元。欲获取更多详情,请访问

Read more
April Wang

TC 北京黑客马拉松

Ubuntu在中国已经举办了两次黑客松了,而这次受TC 中国邀请有机会作为赞助方参加了TC北京黑客马拉松活动。规模当然更高、更大、更尚,这次活动让我们遇到了更多Ubuntu小伙伴们,也让更多志同道合的程序猿们进一步了解到Ubuntu;最开心的是在这次活动中还有遇到之前活动中认识的老朋友呢!

这次黑客松在位于北京五棵松的Hi-Park举行,这里需要特别强调并称赞一下TC中国TechNode队伍的能力和体力,让这个室内篮球场地一夜间变身Hi-Tech Power House. 正巧碰到是万圣节,活动现场诡异事件连连发生。开玩笑了,现场布置是一番万圣趴的气氛,相比寻常黑客松,也另增了一份活泼。

黑客松命题在这次活动中采用了混搭方式, 有三项挑战任务,设有专项命题和作品要求,有机会获得特别的几项大奖;同时开发者们也可以随意出作品做展示,依然有机会获得主办方为大家准备的丰厚礼品。作为命题挑战任务之一的Ubuntu任务,其实算是一个题目比较开放的任务,大家可以通过为Ubuntu手机开发应用或Scope来参与挑战, 也可以通过使用snappy Ubuntu Core来搭建任何智能物联网项目来参与挑战。


这次黑马是正式从第一天的下午1点进入组队开工的,在第二天的上午9点半就开始提交作品, 实际真正写打码的时间也就是20多个小时的样子。作品展示是在次日上午10点钟正式开始的,一共有29组成功完成了作品展示,这里我们挑俩组针对Ubuntu挑战任务而来的作品介绍一下,希望在之后的日子里能看到所有参加挑战的作品成功上线。



双人小组, 专为难以入睡的你们(夜猫子们)定制。这是一款基于Ubuntu手机的应用,通过播放音乐来协助入眠, 同时这款应用可以和手环对接, 通过手环对人体睡眠状态的检测给到应用提示来调整音乐音量,从而达到你已入睡音乐也停,解决睡意正浓时刻起身关音的痛苦。这款应用巧妙结合使用不同智能设备,完成解决了一个大家都曾遇到过的问题。我已经期待能早日在Ubuntu商店中看到并下载这款应用了。



看这名字大家也大约可以猜到会和我们的snappy Ubuntu Core有些关系了,没错,这款应用通过使用snappy Ubuntu Core利用音频来测算智能设备之间距离的跨平台(ubuntu,安卓和IOS)应用,简而言之就是智能设备相互距离的量尺。听起来仿佛很简单,在这个智能设备日益寻常的今天,它被进一步应用的场景其实展示了更多的可能性。你有想到吗?



TC Beijing Hackathon









Read more