Canonical Voices

Daniel Holbach

Announcing UbuContest 2015

Have you read the news already? Canonical, the Ubucon Germany 2015 team, and the UbuContest 2015 team, are happy to announce the first UbuContest! Contestants from all over the world have until September 18, 2015 to build and publish their apps and scopes using the Ubuntu SDK and Ubuntu platform. The competion has already started, so register your competition entry today! You don’t have to create a new project, submit what you have and improve it over the next two months.

But we know it's not all about shiny new apps and scopes! A great platform also needs content, great design, testing, documentation, bug management, developer support, interesting blog posts, technology demonstrations and all of the other incredible things our community does every day. So we give you, our community members, the opportunity to nominate other community members for prizes!

We are proud to present five dedicated categories:

  1. Best Team Entry: A team of up to three developers may register up to two apps/scopes they are developing. The jury will assign points in categories including "Creativity", "Functionality", "Design", "Technical Level" and "Convergence". The top three entries with the most points win.

  2. Best Individual Entry: A lone developer may register up to two apps/scopes he or she is developing. The rest of the rules are identical to the "Best Team Entry" category.

  1. Outstanding Technical Contribution: Members of the general public may nominate candidates who, in their opinion, have done something "exceptional" on a technical level. The nominated candidate with the most jury votes wins.

  1. Outstanding Non-Technical Contribution: Members of the general public may nominate candidates who, in their opinion, have done something exceptional, but non-technical, to bring the Ubuntu platform forward. So, for example, you can nominate a friend who has reported and commented on all those phone-related bugs on Launchpad. Or nominate a member of your local community who did translations for Core Apps. Or nominate someone who has contributed documentation, written awesome blog articles, etc. The nominated candidate with the most jury votes wins.

  1. Convergence Hero: The "Best Team Entry" or "Best Individual Entry" contribution with the highest number of "Convergence" points wins. The winner in this category will probably surprise us in ways we have yet to imagine.

Our community judging panel members Laura Cowen, Carla Sella, Simos Xenitellis, Sujeevan Vijayakumaran and Michael Zanetti will select the winners in each category. Successful winners will be awarded items from a huge pile of prizes, including travel subsidies for the first-placed winners to attend Ubucon Germany 2015 in Berlin, four Ubuntu Phones sponsored by bq and Meizu, t-shirts, and bundles of items from the official Ubuntu Shop.

We wish all the contestants good luck!

Go to or for more information, including how to register and nominate folks. You can also follow us on Twitter @ubucontest, or contact us via e-mail at


Read more
April Wang




  • 图标更新,包括应用和提示类图标
  • Shell rotation
  • 增加了更多欧洲小语种语言类键盘,包括罗马尼亚语,苏格兰盖尔语,希腊语,挪威文,乌兰克语,斯洛伐克文,冰岛文


  • 默认聚合类新闻,照片,和今天Scope中都已经支持关键词标注


  • 退款功能 (Ubuntu商店目前允许用户在购买应用后15分钟内取消订单)
  • 新增应用评级编辑


  • 新增书签文件夹
  • 键盘便捷键功能


  • 改善了来电转发的用户界面(在系统设置 > 手机)
  • 添加了WPA企业级支持到系统设置和网络中
  • 在魅族MX4手机上实现了,通过LED闪灯提示用户手机有最新提示讯息
  • 新增在拨号和短信应用中编辑联络人信息的功能
  • 支持在拨号和短信应用中使用群发信息
  • 添加了GPS位置标注到照相机中
  • SDK最新添加了让显示屏持续开启的功能(例如,在游戏开发中,开发者可以避免屏幕自动超时黑屏的情况)
  • 另外还修复了50多个小八哥

Read more
April Wang



To celebrate the Developer Edition Ubuntu phone launch in China, Canonical organized a “celebrate Ubuntu” hackathon for phone in Beijing. It is also hosted as part of the on-going China Mobile & Ubuntu Developer Innovation Contest, all projects that were coded during the hackathon can be submitted into the contest afterwards.  This 30+ hour hackathon was packed with creativity, excitement and laughter, it was exhausting but amazingly fun.

With the help of media partners (TechCrunch CN, Tech Noda), local tech partners & communities (GitCafe, MS OpenTech,  Ubuntu Kylin, Kaiyuanshe, SegmentFault, CSDN, linuxCN, OSCN, Linuxeden, QTCN,, there are over 120 people signed up online pre-hackathon, and 70+ people turned up onsite.



Being the first ever Ubuntu phone hackathon in China, it doesn’t have any fixed topic and project requirement, as long as it will run on an ubuntu phone in the end. The entire hackathon was driven by pure innovation and creativity.

Ideas and solutions to problems that can benefit or provide entertainment for phone users is the key for this hackathon. There are 7 different awards to be given out to credit different types of ideas.

  • Avant-garde Award - for the most innovative ideas and projects

  • Geek Award - for hardcore techy geeky projects

  • Foolproof Award - for most user friendly projects

  • TalkDaTalk Award - for best project demonstration

  • Stunning Award - for best design projects

  • Entertaining Award - for most fun and entertaining projects

  • Special Content Award - for certain most needed content providing categories

And every team who stood up and provided a project demo received a final demo prize.

Final judging panels were made up by teams from Canonical and China Mobile device company. Each project are being reviewed by its creativity, usability, problem solving level, technical difficulty, design and the completion level. 30 hour straight hackathon is an intense exercise, there were 14 teams in the end proved their talent and effort through their live demo sessions. Four Meizu MX4 phone were given out for the top 4 teams, and all final teams received a Qt Core Tutorial book and numerous small gifts.



A live weibo tweets & hackathon countdown wall, that was put together by @penk , provided a great live interactive platform for onsite participants and online fans and community members.


The 30+ hour hackathon was fueled with energy, determination and of course food, water, cans of redbull & sweets! :) Here is a few clips on how the energy and creativity was flowing throughout the event.
Some of the teams were fresh learners, spent the first day learning and second day coding. However, some of them in the end were part of the final winners too!


Then of course, all work and no play makes Jack a dull boy. Various gaming sessions and polaroid fun took place naturally to keep things alive and exciting!




Now let’s take a look at some of the finalists and their amazing work after the 30 hour hackathon.

Douban FM

A great qml app with neat design and smooth user login experience, which also enables multi device sync up under your own account.  Coded by the one man(the guy on the right hand side of the picture) team @DawnDIYSoft, who is also the man behind the current youku scope in the Ubuntu store



A brand new programming language, which was re-implemented with an interpreter built with JavaScript and ported to Ubuntu phone. Their project can be found here on github.  As you have probably guessed by now, they are of course the winner of the Geek Award, which was presented by Caobin, Project Manager from the China Mobile Device Company.


Memory Dictionary
Utilizing fragmented time slots in your life, such as when you are travelling on a metro train, to memorizing new words and phrases (English language learning app). The app was already built for MacOS, iOS and Android, and is very popular on those platforms. During the hackathon, the team ported it to Ubuntu phone based on cordova.


Couple Like:

An html5 app that compares two person’s pictures to provide a conclusion on what type of couple the two will make. It’s light hearted, fun and packed with love, coded by a team of couple who were on the dance floor not long before the demo.  Also one of the project that runs smoothly on the phone by the end of the hackathon.


Dou Dizhu (poker game)

A single poker game with it's own memory management system and AI. It was implemented in qt widget, so still need some work to port it to Ubuntu phone. But through the desktop demo, it already looking addictive and entertaining.


Utu / uPhoto

It’s an app implemented with C++ for image/photo processing, still a WIP project, but exciting enough for us to know that soon we can beautifying our snapshots on our Ubuntu phone.  


uChat/(Ubuntu Chat)

A dating messaging service application dedicated for anyone who finds it difficult to make the first move or the right move when it comes to meeting someone. It involves server side and client side technology, despite their initial plan of using html5 based on webapp or cordova, the prototype in the end was built with qml by a team of university students in their second and third year.


A few more clips of the hackathon and of course a happy group shot.



Read more
April Wang

2015年7月4-5日,我们聚集北京一起经历了Ubuntu手机在中国的首场黑客松。@DawnDIY最近发布了一篇细心记录下的活动回忆录, 在这里和大家分享。 

Ubuntu Hackathon

 2015年07月08日  DawnDIY


很早就知道"黑客松"(Hackathon),也关注过一些国内的 Hackathon 活动,只是一直都没有去尝试参与过。以前是没有美工前端,所以自己变成了个野生渣前端。最近很长时间都在关注 Ubuntu Touch 的进度,得知有在北京举办 Hackathon 活动,也就迅数报名了。好吧,我的第一次 Hackathon 献给 Ubuntu 了。


当然这次 Ubuntu Hackathon 是为 Ubuntu Touch 开发应用。Ubuntu Touch 上的开发基本分三类。

一是 Scope,Scope 目前在中文也没有很合适的翻译,官方也没有给出中文名称我们都以 Scope 来叫它就好了。开发 Scope,官方给出了一个框架并提供了各类API,可以快速的做出一个不错的 Scope,具体可以参见这里 (友情提示: 网页底部有切换简体中文的链接)

二是 QML App,这也是真正意义上的 Native App 吧。使用 QML 语言进行开发,当然可以结合Qt使用C++对其做支持。

三是 HTML5 App,HTML5 应用,当下比较流行吧。因为今年的 HTML5 标准正式发布,和之前各种宣传,HTML5技术也多用于移动设备开发,最大的好处就是 write once, run everywhere 。

四是 Webapp,这个其实就没什么了,可以把现有的网站 url 打包成一个简单的入口 webapp。其实就是一个网站的快捷方式。

对于 Qt/QML,虽然很早也知道了解过,但从来没写过东西。那Qt是用的C++,好久没碰了。其实 QML 里面可以直接写 Javascript 也不用担心太多,真是万能的 Javascript 啊。那后来发现一些比较复杂不方便在QML里面做的事情,还有一些敏感的内容不能直接暴露在 QML 里面,那么就只能用 C++ 了,写了一段时间发现真的是生疏了。后来 Google 之发现有人说可以用 Golang,瞬间欣喜起来,自己学习过 Golang 也做过一些项目,而且也在期待 Google 将其用在 Android 开发上。然后就得知了 go-qml 这个项目后,就开始深入使用 QML 结合 Golang 来做 GUI 应用。其实 go-qml 的作者也说了,这个库属于 alpha 阶段,而且确实从 v0 到 v1 的时候有些写法和API也确实变了,读了部分源码后发现源码里面一些 Comment 也标记了一些 TODO 和 疑问。所以就当实验性开发吧,不过现在用过来并没有发现很多问题,唯一比较麻烦的就是 Golang Type 到 QML Type 的转换上面有限制。

对于 Scope,第一感觉就像是 Android 里面的 Widget。后来慢慢啃文档也就慢慢理解了,Scope 主要的作用也就是作为一种对信息的聚合、展示、搜索等功能。Scope 可以聚合子 Scope 的信息,也可以对子 Scope 进行搜索。不过目前的 Scope 在功能性方面还是不是特别多,并且 Scope 里的 previewwidget 的功能目前也比较弱,使得很多想象力被限制了。所以 Joey Chan 和 校长 也都和我说 Scope 也就那样了,做 App 吧。So... Learn by doing...


7月4~5日,自从 Rex 那里知道有 Hackathon 以后这个日子已经期待很久了,终于来了~由于最近比较忙,4日凌晨1点才睡觉的,也没怎么准备早上7点40起来,随便把电脑、各种线往书包里面塞,另外还带了我做了特殊处理出国网络比较快的 Raspberry Pi2~

9点多到了 Microsoft 大厦,后来回想起来倒是怪怪的,抱着装着 Ubuntu 的 MacbookPro 去了 Microsoft 大厦参加 Ubuntu Hackathon~呵呵~

一进会场~哇,有美女接待,一紧张忘记拍照了,后悔啊~~~然后默默地找自己的名字,然后弱弱地说我没有团队一个人来的 :) 。找到一个比较靠前的 8 号桌坐下来了。整理好东西,坐下等待安排了。瞬间发现0点钟方向坐着刘老师、11点钟方向坐着 Rex 和 Penk 。刘老师之前见过,Rex第一次见面,不过看见他一直拿着笔记本蹲跪在地上忙,就没过去打扰了。后来上前和刘老师打了声招呼然后聊了会儿之前我和他说用 Golang 的事情。

Rex 和 Penk 上台做简要介绍,Rex 介绍说已经有国内开发者在开发 Ubuntu Touch 平台的 App 了,出现了 Joey Chan 的 AesyWeibo,然后PPT上突然出现我之前做的 Youku Scope,嘿嘿~欣喜一下。然后 Rex 说 Youku Scope 是在场的一位开发者做的,问他在哪。我开始懵了一下然后站起来,只见 Penk 在那喊了一声,“原来就是你啊”。然后继续,今天的主题就是没有主题。Let's start...

现场很多人是没有 Nexus4 或者其他可以运行 Ubuntu Touch 的手机,于是官方向每一桌提供开发机。哇,是刚才签到的妹纸来发~~只见快到我这桌了,好紧张,然后就看到她默默地走过去了,略过我这桌了,为什么?我很费解,此时 Penk 突然在我面前坐下了。好吧,妹纸走了,Penk大神来了~哈哈,都不用相互介绍我们就聊起来了,问我要做什么,我说还没想好,可能做个音乐相关的吧。Penk说要不要把Youku Scope 完善一下,也行...然后 coding...

为 Scope 添加 Account 功能之前还没看,这下顺便开一下,还请教了几次刘老师,遇到了挺多困难的。后来休息一下,想想,还是尝试做新的东西吧,这样在限时里完成才有挑战,那好,开启 QML 模式~ 之前就想在 Ubuntu Touch 做类似豆瓣FM的app,那好就定这个了~

哈哈,晚饭居然可以自助选择盖饭和麻辣烫~ 吃饱喝足继续 Hack~ 不过每次红牛都被抢光了,都是结束的时候 Rex 分了我一灌,感谢~


我算是坚持的比较晚的吧~4日晚上基本没睡,电脑里面一直循环着一些 Death Metal。邻座的一组貌似还是外地来参加的学生,他们也比较努力也都好多没睡,听他们在讨论,发现年轻真好,比我在大学的时候强多了!PS:刘老师混进了同学们中,开始还在聊技术,后来还聊到大学生活,刘老师真能聊,哈哈~~

5日凌晨的时候还遇到了一个好玩的事情~调试了一个微博的接口,用到了上传图片,由于权限的问题,我只能上传整张图片,而不能给定url。这个接口调了我好久,就是为了能有一个分享音乐的功能,后来去请教 Penk,Penk 也是一夜没有睡了佩服!向 Penk 说了一下后,他理解了我的思路也确定没问题,但怎么就不行了呢~调用微博的接口总报错不给通过,好吧,吐槽一下微博的文档好多细节没写好。见 Penk 也是一夜没睡,很累的样子,感谢听我瞎扯~ 后来自己想办法吧!快速用 Python 在本地做了个服务,直接发请求到本地,看看是不是自己的问题,瞬间条理就清晰了~哈哈~ Penk 给我当了一次小黄鸭~后来在厕所碰到 Penk,兴奋的和 Penk 说了我怎么解决的~ 回来后瞬间感觉又有能量了,直到坚持到7点后吃了 Joe 提供的早餐,我就小睡了一会儿~~~

Debug 到早上8点,基本要完成的都完成了。嘿嘿~豆瓣FM for Ubuntu Touch ! 还有一个离线播放的功能还没做完,因为目前没法精确判断 WiFi 和 移动数据 的状态,不过已经有人在 Launchpad 上提交 Bug 了。PS: 其实 Ubuntu Touch 现在就像一个小孩子,我也是慢慢看着它一点点的变化,要不是平时很忙,我恨不得仔细读读所有的源码,把一些我发现的 Bug 直接 fix 掉再提交。呵呵,我早晚会仔细研究其源码的。不过我还是贡献了挺多翻译的~


  • 尺子
  • Couple like
  • 优图
  • 斗地主
  • 日记本
  • 记忆词典
  • 路痴助手
  • uChat
  • rocket 拼图
  • LoLi team(mb)
  • 撞脸
  • 小飞机
  • 需求交互
  • 豆瓣FM for Ubuntu touch

上面的就是小伙伴们30个小时的奋战成果!值得一提的是其中有些朋友是刚开始学习开发,尺子的作者他就提到他也是学习 C++/Qt 不久,但我觉得尺子这个作品很实用的。

Couple Like 是一对搭档完成的,嘿嘿,这个创意不错,是一款通过图像人脸识别辨别其年龄以及两个人的匹配程度的应用。最强的是演示时候用的 Demo 图片。

斗地主、日记本等那些,原来大家都是qt高手啊,都在 Ubuntu 平台上实现了很好玩的应用。希望早日在 Ubuntu Touch 见到。

值得一提的是 LoLi team 他们在用 Js 在 Ubuntu Touch 上实现了 LoLi 的解析器,LoLi 是他们自己发明的一个 Lisp 的方言,纯技术层面来说,这个很牛啊~佩服佩服~而且让我感觉到年轻真好~~要哭了

uChat 一款基于 LBS 的社交应用,是一组在校的同学做的,他们做的演示和理念都不错,我以前也想过一个类似的应用~

轮到我的 豆瓣FM for Ubuntu Touch 登场了~哈哈~可能一晚上没睡,感觉自己演讲的不好吧~随便整理了一个slide, 这个 slide 也是开源的哦,大家可以folk,里面有一些有用的资料。借用 Rex 的电脑简单的把 slide 讲了一遍,还是那句话,因为我喜欢音乐,所以我做了相关的应用,这样真的很开心。然后就是演示了,点击应用播放的刚好是 自然卷 的单曲《坐在巷口的那对男女》,大家都挺熟悉的,当我把话筒对着手机的扬声器时,大家听见音乐都鼓起掌了。谢谢大家喜欢,然后介绍了一些必要的功能(后来发现其实我好多忘记演示了),然后...然后就没有然后了... No~还有 One More Thing... 大家听到还有"One more thing"的时候有惊奇起来。为了纪念这次活动,我在 豆瓣FM for Ubuntu Touch 中制作了一个彩蛋,嘿嘿,只有特殊的方式才能进去的哦~大家看到后都哈哈大笑起来。待我把它完善好后,大家自己去发现吧 :)


第一次参加 Hackathon,感觉很充实,也认识了很多朋友。最好的感受就是和一群兴趣相投的朋友做自己爱做的事情真好~最后就是回家睡个天昏地暗~


Read more
David Callé

Add a C++ backend to your QML UI

Whether you are creating a new app or porting an existing one from another ecosystem, you may need more backend power than the QML + JavaScript duo proposed in the QML app tutorial.

Let's have a peek at how to to add a C++ backend to your application, using system libraries or your own, and vastly increase its performance and potential features.

In this tutorial, you will learn how to use and invoke C++ classes from QML and integrate a 3rd party library into your project.

Read the tutorial

Read more
April Wang

Pawel Stolowski于2015年6月11日发布一篇名为“Cleaning up scopes settings”的博文,我们在这里简单翻译转发和大家分享一下。

Unity 7(在当前桌面上提供Ubuntu shell和默认UX体验)和Unity 8(支持手机且很快将支持融合桌面)在数据源可见性方面存在很大程度的差异。未来Unity 8版本将废弃过去遗产的隐私标记,会更偏向于一种更加清晰的方式,让用户自己决定将数据发送到哪里。

Unity 7中的Scope搜索并保存隐私 

在默认情况下,在Unity 7中使用常规Dash搜索时,它将首先联络Canonical的智能Scope服务器,该服务器会推荐适合搜索关键词的最好或最相关的Scope。然后,下一步是在这些Scope中筛选查询到实际结果,然后呈现出来。


Unity 8中的Scope搜索

Unity 8中的Scope体系结构截然不同:整个搜索过程不会涉及到智能Scope服务器。


如果是在使用一个聚合类Scope的情况下, 其中聚合了不同数据来源的子Scope,它的设置页面内会列出所有聚合了的子Scope。用户可以选择自行设置禁用每个单独子Scope的数据源。 

Unity 8废弃了过去遗留的隐私标记

由于在Unity 8中进行内容搜索查询时,可以清晰的看到并且可以轻松禁用Scope及其子Scope的数据源,隐私标记自然就变成了多此一举多余设置。正因如此,我们决定在我们的手机系统/ Unity 8后续简介中去掉清除这一项过去遗留下的设置。

如果你在Unity 8中有使用这一标记,其实通过取消收藏设置(在手机上点掉星号设置)或禁用聚合类Scope中对应的子Scope数据源都可以达到相同的效果。你还可以卸载独立Scope。

在Unity 8中保护隐私

在shell中,你可以看到两种Scope:普通独立/品牌类Scope和聚合类Scope。品牌类/独立Scope可以访问自己独立数据源,但不能同时访问其他或此品牌之外的数据源。因此,例如名叫“我的音乐”的Scope,将仅查询你的手机上本地的音乐文档,而名为“BBC News”的Scope也只能查询到的新闻内容。如果你不希望使用“BBC News”Scope,就不调用(通过manage dash)或收藏该Scope(类似于不调用网页应用程序)。



Pawel Stolowski工作于Unity API团队,致力于开发并实现Unity Shell搜索功能的Scope中间件及API有关的工作。他还致力于实际Scope(例如Music、Video、Apps等等)的开发以及Ubuntu Linux相关的其他项目中。大家可以通过Twitter关注Pawel - @pstolowski

Read more
Pawel Stolowski

Cleaning up scopes settings

The scopes architecture on Unity 7, which provides the Ubuntu shell and default UX experience on current desktops, and Unity 8, which powers the phone and soon the convergent desktop, differ to a large degree when it comes to visibility of data sources. Future Unity 8 builds will be obsoleting the legacy privacy flag in favour of a clearer way for users to decide where the data is being sent to.

Scope searches and preserving privacy in Unity 7

By default, using a regular Dash search in Unity 7 will first contact Canonical's smart scopes server, which recommends the best or most promising scopes for the search term. Then, as a second step, those scopes are queried for actual results, which will finally be presented.

However, this approach means that the user doesn't necessarily know in advance which scopes are queried and that the search term will be hitting the smart scopes server. Although the data sent to server is anonymized, we understood that some users might still be concerned about data privacy. It was for that reason that privacy flag was introduced: a setting for scopes that prevents access to the smart scopes server.

Scope searches in Unity 8

The scopes architecture in Unity 8 is quite different: there is no smart scope server involved in the search lifecycle.

Instead, each query is only sent to the currently  active scope (that is, the one that is currently visible), so that the user always knows where their search data ends up.

For the case where the current scope being is aggregating multiple other scopes, its settings page will list all aggregated scopes, offering the possibility to individually disable each one if desired.

Obsoleting the privacy flag in Unity 8

With this clear visibility of what's being queried, and the possibility to easily disable sources/scopes, the privacy flag becomes redundant in Unity 8. As such, we have decided to remove this legacy setting in one of our phone/Unity 8 next snapshots.

If you have been using this flag under Unity 8, either unfavorite or disable the respective scopes from the aggregator settings to reach the same result. You can also uninstall the individual scopes.

Creating privacy in Unity 8

In the shell you can see two kind of scopes: normal scopes and aggregator scopes. Normal scopes can access either local or remote data but never both at the same time. So, if there is a scope called “My Music” then this scope will only query your phone, while a “BBC News” scope will only query If you don’t want to use “BBC News” scope then do not invoke (via manage dash) or favor the scope (similar to not to invoke (web)apps).

Aggregator scopes in contrast can aggregate all kind of scopes whether they access local or remote data. If you’re concerned about a specific scope you can disable it via the scopes’ settings page that lists all scopes being aggregated. However, given that most scopes deal with remote data, it will be faster to just unfavorite the respective aggregator via “Manage Dash” and favorite the interesting scopes dealing with local data like “My Music” or “My Videos”. This has also the benefit of not having (almost) empty dash pages.

Read more
April Wang

上周西班牙手机厂商BQ和Canonical再次联和发布又一新款Ubuntu手机 - BQ Aquaris E5 Ubuntu版本。 这也是BQ厂商发布的第二款Ubuntu手机, 这一次带来了更大的屏幕和更加强悍的摄像头硬件, 还有增强的电池容量,让这款手机待机更久。 

2015年6月9日,英国时间, 这款最新Ubuntu手机正式开卖。 售价199.9欧元(约1399.31元人民币), 比之前的BQ Aquarius E4.5 Ubuntu版本手机贵了约30美金(约190元人民币)。 我们来看一下, 这款最新Ubuntu家族的成员到底新意何处。 

Aquaris E5的硬件配置:

这款E5 Ubuntu手机只有一个颜色 - 黑色, 内存16GB

硬件配置来说, E5其实和前一款Ubuntu E4.5区别不大, 同样使用联发科技的四核处理器,搭配1GB的RAM。 

最大的硬件提升是来自E5相机的。 E5机身前置和后置的相机都装配了BSI感应器和Largan镜片。 后置相机拍摄的照片像素可达1300万像素,而前置相机可达5百万像素。 

另外E5还带有一个MSD卡片插槽, 可以将总内存增加到32GB。 

目前这款BQ E5的Ubuntu手机仅限欧洲售卖,而且将会在6月22日开始发货。

此外Ubuntu酝酿很久的融汇Convergence口袋PC手机也在积极开发中。 让你的手机直接插上一个显示频, 键盘和鼠标就能当做PC来使用的话, 想想就很让人鸡冻\(≧▽≦)/!

Read more
Zoltán Balogh

Sprinting for convergence

Convergence is all around. Our deeply loved UI Toolkit, what was primarily targeting touch environments is converging to where users might have keyboards and pointer devices. But that is just one point. The innovative track for Ubuntu is called Snappy and at the same time the SDK is converging to the desktop. We move to the direction where frameworks and applications are packaged and distributed in a new model. It is exciting to see how the different development tracks do move in the same direction.

Last week the SDK team has spent quality time with the creative folks from the design team and with master ninjas from the QA team to put down the foundations of a converged UI Toolkit and SDK.

We had two major questions when we entered the sprint:

How UI Components will look and behave when pointer and keyboard devices become available even during runtime?

How can we enable scope and application development for literally any kind of Ubuntu device?

Our offering is not only for smartphones. The UI components are as good on a big screen desktop as on a tablet sized device or on any small device with a screen. I totally can imagine the UI Toolkit on a car’s infotainment dash or on a control panel of an intelligent house. But before the bold dreams we focus on bringing the components to the classic desktop environment.

Application convergence

When we talk about convergence we mostly mean application convergence. The “definition of done” is when one can start an application on a touchscreen phone and the application scales and adapts automatically to a bigger screen with keyboard and mouse when plugged into the device.
The driving applications are Ubuntu browser, dekko email client, music player, calendar, document viewer, messaging, address book, snap decisions/alerts and Telegram.

As an addition the toolkit will provide API to control window and page sizing, a component to easily transition from a one column pagestack to a multi-column view, supporting 2 or more columns. A detachable header component is also planned, so applications can put headers in different views, not only in a MainView. But more about these in the following.

Foundations and tools

To make a converged SDK we do need a solid and sustainable foundation. Not only the UITK depends on the Qt stack but our own IDE needs it. On the sprint we already made working prototypes of distro decoupled Qt and IDE packages. In other terms it means that we can produce the Qt, UI Toolkit and SDK Tools snappy packages pretty much any time when needed. The cool thing in keeping our eyes on snappy is that this new structure motivates us to cut the loose ends from our packages and make the SDK more portable and easier to build.

The promise is that we will have distro independent (snappable) SDK tools and UITK with Qt 5.4 for anything what is compatible with the 14.04 Ubuntu.

UI Toolkit 2.0 plans

Improving the performance and the overall quality are the keywords for UITK 2.0. We will list those components what would perform better if they were implemented in C++, starting with MainView as it is needed for the Convergence story.

We want to upstream the UITK to Qt. Living close to our upstream foundation brings great value. Refactoring the source tree to have a single Ubuntu.Components module without submodules is the natural first step towards upstreaming. It will make the UITK more compatible with other Qt modules. Early bits might land on 1.3 depending on the needs. The detailed API planning will start end of Ubuntu 15.09 and is planned to land on 16.04.


The scopes toolkit will slowly migrate from the Unity8 space to the UI Toolkit. It means that the components used now for scope development will be available for classic application development. Also the scopes APIs are under heavy re-factoring. According to the present plans the UITK will be available to the scopes and scopes will become more active aggregators than ever. The key point with scopes is that we will put lots of effort on scopes development as they are one of the most visible differentiation from other platforms.


An issue with the current version is the thumb is covering actions in the UI because it can not be positioned outside the window and if users approach an action on the right hand side the thumb is revealed. The scrolling user experience will be the same as in Unity7 with the exception that the thumb appears inside the window area. The thumb follows the mouse cursor position and hides when the mouse does not move. The design team is currently prototyping two different scrollbars, one with a thumb and one without, which visually would look the same as in Qt Creator for example, and we will evaluate which fits better to the designs and will release the most appropriate and usable one.


When mouse pointers are available the tooltip appears when hovering over a component. With a touch interface a long press interaction is under investigation which would invoke a tooltip on a component or action..

The tooltip appears under the mouse cursor after a timeout (1 second), positioned the same way as popovers, and disappears after a timeout (10s) or when the mouse is moved out of the component’s area.

Date and time pickers

This is one of the components which got a heavy design facelift. The components are no longer tumbler based Pickers, but composed of an editable component, which when tapped/clicked opens a popup, in which there can be a calendar component for date picking, or a picker for time picking. The main component is a text input with no text cursor, when activated with keyboard, the entire content will be selected, and can be edited at once, i.e. no positioning will be possible. The popups will be full screen dialogs on screens smaller than 40x71 GU, and popovers on bigger screens.

Dropdown Menus & popovers

We are considering to reuse QtQuick Controls Menu components, adapting those to the toolkit’s theming and actions. Keyboard shortcuts and accelerator will only be visible with mouse/keyboard attached in any drop down menu. The context menus will be single level menus in the first iteration and cascading menus might come later if needed. The individual application menus are not high priority but we will listen to the app developers and hear what they need.

Expandables, ListItems module

As now we have OptionSelector and ItemSelector what is confusing, and neither of them is configurable enough. The old Ubuntu.Components.ListItems has a pile of components which is just not flexible enough, and they are all underperforming. Expansion will be introduced to the new ListItem, and new layouts will be made which will be flexible enough to survive eventual design changes. This is not a high priority for convergence, however it will serve as a ground for phone and desktop layouts as well as the prerequisite for the application menus. We will keep trying to separate the layout from the ListItem, hopefully we will manage to do that performantly enough.

Accessing ListItem actions on desktop

At first, a mouse right click will bring up a `contextual` menu which will contain leading, trailing and default actions, as well as selection/drag modes, without any API change on ListItem. After application menu will be implemented, we will enable the context menu on the ListItem together with other components.

Panels behaviour & MultiColumnView

For the 2-column pagestack we still need to find out the best navigation model, more precisely the way we handle the headers of the pages, cascading or not. We gathered the tasks we have to complete in order to provide convergent view handling:

  • PageStack cannot be adapted to the new UX without major API changes, therefore we will introduce a component called MultiColumnView, which can transition from one column to 2 or more columns. The component will put Pages side by side, and will maintain a stack depending on where the page is pushed, above the current page or next to it. Applications using this component must specify the minimum and maximum sizes for the page

  • Title, or header handling should be detached from MainView, and there will be a Header component which then can be used in bottom edge, or a ListView’s header component

  • The bottom edge will be used on the desktop, and there will be a component called BottomEdgeHint which provides a clickable component if there’s a mouse. The bottom edge swipe known from the touch environment will simply translate a new clickable component what will appear when the mouse is hovered on it. The content of the component (for example a pagestack) depends on what the developer wants.

Focus handling

The focus handling concerns not only TAB/Shift+TAB navigation between components, but also the keyboard navigation inside composite components, such as ListView, ComboButton, text inputs, header, etc. The focus highlight is more or less agreed, however there is a little prototyping ongoing to figure out whether we can do some nice effects on it or not.


Read more
Daniel Holbach

Thanks to the tireless work of Oliver Grawert we now have a handy tool called node-snapper which very easily turns your node.js project into a .snap package. It will automatically take care of bundling required libraries, other related node.js projects and will make a multi-arch ("fat") package available, so it will immediately work on armhf and amd64 architectures.

Intrigued? Check out our tutorial Turning node.js projects into snap packages.

Read more
David Callé

Have you taken Vision Mobile’s developer survey? The survey is covering your development in Mobile, Desktop, Cloud, and IoT this year, there is something all devs can contribute towards and help shape the findings for this survey.

Participating is easy - take the 10-minute Developer Skill Census survey and enter a draw to win prizes such as the BQ Aquaris E4.5 Ubuntu Edition, iPhone 6, Apple Sports Watch, Oculus Rift Dev Kit, and many more. A free chapter from one of VisionMobile’s premium paid reports will also be given immediately upon completion, taking a close look at app profits & costs.

The survey closes on 5th June - enter the survey now

Thanks to everyone who has already completed the survey!

Read more
Christian Dywan

We all love QML because it allows for fast prototyping, and not only that, it's a very efficient tool for production applications. The complexity of C and C++ is hidden behind neat and simple API. Many if not most app developers these days take advantage of that without even having to know the implementation details. Most of the Ubuntu UI Toolkit is pure QML except for performance-critical elements like the new ListItem or the theming engine.

There's a notable flaw however to QML as a language when it comes to versioning. Any QML component is made known to the engine in one of two ways. Using qmldir, which essentially is a text file listing with version numbers and filenames - unfortunately there's no error handling whatsoever so qmldir files in productive use are all but flawless and mistakes including missing files won't be noticed easily, made worse by the fact that QML automagically recognizes files as class names regardless of being registered anywhere. The other way is qmlRegisterType in one of its various incarnations - seemingly with inbuilt support for minor revisions which in fact are completely unrelated to QML.

Looking further at how classes behave it's not looking much better either. There's no support for versions in functions, properties or signals. All members will show up in all versions the same QML file is registered to. Additions as well as changes affect all versions - unless you fork the implementation, which is what we do for the Ubuntu UI Toolkit these days to ensure new versions don't break existing code, with the exception of bug fixes. To make matters worse, if the implementation imports another, newer version, the public API will follow suit. Regardless of the policy of a particular project, there's no easy way of ensuring the public API is what you want it to be, it's just too failible.

Fortunately the Ubuntu UI Toolkit has employed a solution that's now become available for everyone:


Usage: apicheck [-v[v]] [-qml] [-json] IMPORT_URI [...IMPORT_URI]

Generate an API description file of one or multiple components.
Example: apicheck Ubuntu.Components
    apicheck --json Ubuntu.DownloadManager

The following rules apply for inclusion of public API:

 - Types not declared as internal in qmldir
 - C++ types exported from a plugin
 - Properties and functions not prefixed with __ (two underscores)
 - Members of internal base classes become part of public components


It's designed to serialize the public QML API in a way that is human readable as well as easy to process in a pogrammatic fashion. Let's try it out, shall we?

/usr/lib/x86_64-linux-gnu/ubuntu-ui-toolkit/apicheck Ubuntu.Components >

This will give you something like the following in the file

Ubuntu.Components.PageHeadConfiguration 1.1: Object
    readonly property Action actions
property Action backAction
    property Item contents
    property color foregroundColor
    property string preset
    readonly property PageHeadSections sections
Ubuntu.Components.PageHeadConfiguration 1.3: Object
    readonly property Action actions
    property Action backAction
    property Item contents
    property color foregroundColor
    property bool locked
    property string preset
    readonly property PageHeadSections sections
    property bool visible
Ubuntu.Components.UbuntuShape.HAlignment: Enum
Ubuntu.Components.ViewItems 1.2: QtObject
    property bool dragMode
    signal dragUpdated(ListItemDrag event)
    property bool selectMode
    property QList<int> selectedIndices
Ubuntu.Components.i18n 1.0 0.1: QtObject
    property string domain
    property string language
    function bindtextdomain(string domain_name, string dir_name)
    function string tr(string text)
    function string tr(string singular, string plural, int n)
    function string dtr(string domain, string text)
    function string dtr(string domain, string singular, string plural, int n)
    function string ctr(string context, string text)
    function string dctr(string domain, string context, string text)
    function string tag(string text)
    function string tag(string context, string text)

There are, in order, a QML component, an enum, an attached property and a singleton, all read from the typesystem in the way they will be available to QML applications.

Now in addition to reviewing this file with the naked eye you also use diff:

diff -F '[.0-9]' -u components.api{,.new}

Now let's imagine we're making some changes to some of the classes and running it again will yield this result:

@@ -415,11 +415,11 @@ Ubuntu.Components.PageHeadConfiguration
 Ubuntu.Components.PageHeadConfiguration 1.3: Object
     readonly property Action actions
     property Action backAction
-    property Item contents
+    property var contents
     property color foregroundColor
     property bool locked
     property string preset
-    readonly property PageHeadSections sections
+    property PageHeadSections sections
     property bool visible
 Ubuntu.Components.PageHeadSections 1.1: QtObject
     property bool enabled
@@ -1001,7 +1001,7 @@ Ubuntu.Components.UbuntuShape.FillMode:
 Ubuntu.Components.UbuntuShape.HAlignment: Enum
-    AlignRight
+    AlignTop
 Ubuntu.Components.UbuntuShape.VAlignment: Enum
@@ -1017,7 +1017,6 @@ Ubuntu.Components.UriHandler 1.0 0.1: Qt
 Ubuntu.Components.ViewItems 1.2: QtObject
     property bool dragMode
     signal dragUpdated(ListItemDrag event)
-    property bool selectMode
     property QList<int> selectedIndices
 Ubuntu.Components.i18n 1.0 0.1: QtObject
     property string domain
@@ -1027,7 +1026,7 @@ Ubuntu.Components.i18n 1.0 0.1: QtObject
     function string tr(string singular, string plural, int n)
     function string dtr(string domain, string text)
     function string dtr(string domain, string singular, string plural, int n)
-    function string ctr(string context, string text)
+    function string ctr(string context, string text, bool newArgument)
     function string dctr(string domain, string context, string text)
     function string tag(string text)
     function string tag(string context, string text)

See what happened there? Several changes show up in the diff output, including changed arguments, removed and added members and even the removal of the readonly keyword.

In the case of the Ubuntu UI Toolkit a components.api file lives in the repository. A qmake target generates from the local branch and prints a diff of the two files. This is run as part of make check, meaning any changes to the API become visible at the time you run unit tests, as well as CI builds for merge requests made on Launchpad. Any changes will cause make check to fail so the branch has to include an updated componets.api which shows up in Launchpad reviews and bzr command line tools.

If any of this got you excited, maybe you wanna add it to your own components and improve QA?

Read more
David Callé

Are you involved in Ubuntu phone, desktop, cloud or IoT development? Voice your opinion on what factors contribute to your choice of developing on Ubuntu by getting involved in the biggest developer survey yet.

Vision Mobile have launched their 9th edition developer economics survey today, covering developer sentiment across platforms, revenues, apps, tools, APIs, segments and regions. This ambitious survey covers everything from mobile, desktop, cloud and IoT. Key insights from the survey will be provided as a free download in late July, and a free chapter from one of VisionMobile’s premium paid reports will also be given immediately upon completion, taking a close look at app profits & costs.

Tell us your thoughts about the latest developer trends, take the 10 minute survey now - some amazing prizes are up for grabs including the BQ Aquaris E4.5 Ubuntu Edition, Apple Sports Watch, iPhone 6, Oculus Rift Dev Kit + many more gadgets!

Read more
April Wang

Mark Shuttleworth昨晚揭晓了Ubuntu 15.10 的版本代号 Wily Werewolf。Wily在英文中一般用于描述易于适应环境锐敏足智的角色人物,而Werewolf则是传说中的一种神秘物种,小说中常常以人形出现但会在满月之日变成狼性的狼人 

Ubuntu 15.10 将会在今年10月份发布,而它的代码名也是至今为止Ubuntu版本名中第二个被重复的字母 (另外一组曾被重复使用的字母为H,相关版本名分别为Hardy Heron和Hoary Hedgehog)

为了昨晚有错过直播的筒子们另外再献上 , Mark现场的几段精彩keynote,致即将到来的Pocket PC!

“We [the Linux desktop] were always five, ten years behind. Always copying the other guy. Here, for the first time, we have this vision at the same time,” he said.

“It doesn’t matter [who had the idea first]. We’re living in a world where, if we make a great experience, all the applications that run on a Windows converged experience might also run on a Ubuntu converged experience.”

“I’d like us to rise above kind of saying ‘you’re copying our ideas’. We didn’t patent those ideas. We spoke very publicly about that vision because we wanted it to be true. I think it’s exciting for everybody that [it now is].”



Read more
David Callé

Internationalizing your QML app


As a developer, you probably want to see your apps in many hands. One way to make it happen is to enable your application for translation.

With minimal effort, you can mark your application strings for translation, expose them to community translators and integrate these translations into your package. The translations building process is handled by the SDK itself and if you happen to use Launchpad, translators will quickly see your project and help you, but you still need to mark your user-visible strings as translatable.

Let's get started ›

Read more
Loïc Molinari

A magnifying glass in QML

To create sharp visual components, we need to make sure our renderings look good at the pixel level. This is a common task and the terms precision and pixel-perfectness have become ubiquitous in discussions among programmers and designers at Canonical. In the last years, the industry started to increase the pixel density of screens, again (remember the CRT era), resulting in a higher number of pixels within a specified space (see Retina Display for instance). A consequence is that jaggies are less visible than before because we are reaching the point where the pixels are small enough that the eye is not able to detect them. In an idealized world of high density screens that would completely remove the need of anti-aliasing algorithms to smooth edges, but the fact of the matter is that we are not there yet and we will still have to thoroughly inspect the quality of anti-aliasing algorithms for a while.

Handheld magnifying glass

At a previous job, a colleague of mine used to keep a handheld magnifying glass on his desk. I was quite amused to see him glued to his screen validating the visual quality of commits with this thing. As the graphics engine programmer, I barely remember the reason for which I never proposed the inclusion of a software magnifier, it could be because of the overloaded backlog we had to deal with at the time but I guess it actually was just out of sheer mischief. Most desktop environments include a software magnifier, but depending on its quality (efficiency and ease of use), it often makes sense to integrate a custom magnifier directly in the application being developed (it makes less sense to ship it in release builds though...). This article explains how to implement an efficient one with QML using offscreen framebuffers and shaders.

Offscreen framebuffers (exposed as FBOs in OpenGL), vertex shaders and fragment shaders are now widely available in mobile and mid-range GPUs allowing the creation of interesting real-time post-processing effects for most devices on the market. Magnification, or to be more precise zooming & panning (magnification solely being the process of rendering an image at a higher scale), is one of it. In low-level graphics programming terms, all it takes is to do a first pass that renders the scene in a FBO and a second pass that renders a texture mapped quad to the default framebuffer reading the FBO as a texture. Image zooming and panning is a basic 2D scale and translate transformation that can be efficiently implemented by tweaking the texture coordinates used to sample the FBO at the second pass. The vertex shader, executed for the 4 vertices making our quad, will easily take care of it using a single multiply-add op (transformed_coords = scale * coords + translation) and the hardware accelerated rasterizer and texture units will make the actual rendering very efficient. In order to clearly distinguish the magnified pixels, it is important to use a simple nearest neighbour filter. These low-level bits are nicely exposed to QML through the ShaderEffectSource and  ShaderEffect items. The former allows to render a given Item to a FBO and the latter provides support for quads rendered using custom vertex and fragment shaders.

Here is the QML code of the magnifier:

import QtQuick 2.4

Item {
    // Public properties.
    property Item scene: null
    property MouseArea area: null

    id: root
    visible: scene != null
    property real __scaling: 1.0
    property variant __translation: Qt.point(0.0, 0.0)

    // The FBO abstraction handling our first offscreen pass.
    ShaderEffectSource {
        id: effectSource
        anchors.fill: parent
        sourceItem: scene
        hideSource: scene != null
        visible: false
        smooth: false  // Nearest neighbour texture filtering.

    // The shader abstraction handling our second pass with the
    // translation and scaling in the vertex shader and the simple
    // texturing from the FBO in the fragment shader.

    ShaderEffect {
            id: effect
            anchors.fill: parent
            property real scaling: __scaling
            property variant translation: __translation
            property variant texture: effectSource

            vertexShader: "
                uniform highp mat4 qt_Matrix;
                uniform mediump float scaling;
                uniform mediump vec2 translation;
                attribute highp vec4 qt_Vertex;
                attribute mediump vec2 qt_MultiTexCoord0;
                varying vec2 texCoord;
                void main() {
                    texCoord =

                        qt_MultiTexCoord0 * vec2(scaling)
                        + translation;
                    gl_Position = qt_Matrix * qt_Vertex;

            fragmentShader: "
                uniform sampler2D texture;
                uniform lowp float qt_Opacity;
                varying mediump vec2 texCoord;
                void main() {
                    gl_FragColor =

                        texture2D(texture, texCoord) * qt_Opacity;


    // Mouse handling.
    Connections {
        target: scene != null ? area : null


And here is how to use it:

import QtQuick 2.4

Item {
    id: root

    Item {
        id: scene
        anchors.fill: parent

    ZoomPan {
        id: zoomPan
        anchors.fill: parent
        scene: scene
        area: mouseArea

    MouseArea {
        id: mouseArea
        anchors.fill: parent
        enabled: true
        hoverEnabled: true
        acceptedButtons: Qt.AllButtons


Mouse handling has been snipped off the code for conciseness but it can be studied directly from the code repository. One important point to notice is that for zooming to be a pleasant experience, it has to be implemented using a logarithmic scale as opposed to a linear scale. Each scale value at a zooming level is the previous one multiplied by the desired scale factor, so a scale factor of 2 and a zooming level n give a scale value of 2n. Another point is that to scale an image up, the range of its texture coordinates must be scaled down, this explains why the actual scaling is inverted. So a scale value of 2n would give an actual scaling of 2-n. A bit counterintuitive at first…

We’re done with the theory. Let’s have a look at the final result:


This technique helped me in the making of several visual elements, I would be glad if other programmers find it useful too. Zooming and panning is a very common feature in image viewers, the technique could be adapted for that use case too (with potentially some tweaks to support tiling of big pictures). Maybe that would be a good addition to the Ubuntu UI toolkit, don’t hesitate to ask if you would like official support for it.

The source code is available on launchpad:

Read more
Zoltán Balogh

14.04 - 1.0 release

The 1.0 release of the UITK was built mostly for demonstrative purposes, but works well to a certain extent, it is the LTS release after all. Available from the Trusty archive (0.1.46+14.04.20140408.1-0ubuntu1) and from the SDK PPA (0.1.46+14.10.20140520-0ubuntu1~0trusty2). The “demonstrative purpose” in this context is a pretty serious thing. This release was the ultimate proof of concept that the Qt (5.2 by then) and QML technology with our design and components provides a framework for a charmingly beautiful and killing fast user interface. Obviously there is no commercial touch device with this UITK release, but it is good to make a simple desktop application with the UX of a mobile app. If your desktop PC is running 14.04 LTS Ubuntu and you have installed the Ubuntu SDK then the IDE is using this release of the UITK.

The available components and features are documented either online or offline under the file:///usr/share/ubuntu-ui-toolkit/doc/html local directory if the ubuntu-ui-toolkit-doc is installed.

14.10 - 1.1 release

It was the base for the first real Ubuntu phone. Most mission critical components and toolkit features were shipped with this edition.  The highlights of the goodies you can see on the Utopic edition of the UITK (version 1.1.1279+14.10.20141007-0ubuntu1):

  • Settings API

  • Ubuntu.Web

  • ComboButton

  • Header replaces bottom toolbar

  • PullToRefresh

  • Ubuntu.DownloadManager

  • Ubuntu.Connectivity

The focus of the UITK development was to complete the component set and achieve superb performance. It is important to note that these days, this exact version you can find only on very few community ported Ubuntu Touch devices, and even those early adaptations should be updated to 15.04.  The most common place to meet this edition of the UITK is the 14.10 Ubuntu desktop. This UITK can be indeed used to build pretty nice looking desktop applications. The Ubuntu specific UI extensions of the QtCreator IDE are built on our very own UITK. So, the UITK is ported and available for desktop app development with some limitations since 14.04.

14.09  - the RTM release

The development of the RTM (Ready To Market) branch of the UITK  was focusing on bugfixes and final polishing of the components. Dozens of functional, visual and performance related issues were tackled and closed in this release.

A few of relevant changes in the RTM branch:

  • Internationalization related improvements

  • Polishing the haptics feedback of components

  • Fixes in the ActivityIndicator

  • UX improvements of the TextField/TextArea

  • Dialog component improvements

This extended 1.1 release of the UITK is what is shipped with the bq Aquaris E4.5 devices. This is pretty serious stuff. Providing the very building rocks for the user experience is a big responsibility. During the development of this  release one of the most significant changes happened behind the scenes. The release process of the UITK was renewed and we have enforced very strict rules for accepting any changes.

To make sure that with the continuous development of the UITK we do not introduce functional problems and do not cause regressions we not only force to run about 400 autopilot test cases on the UITK, but an automatic test script validates all core and system apps with the release candidates. It means running thousands of  automatic functional tests before each release.

15.04 - 1.2 release

After the 14.09 aka RTM release was found good and the bq devices started to leave the factory lines the UITK development started to focus on two major areas. First of all we brought back to the development trunk all the fixes and improvements landed on the RTM branch and we merged back the whole RTM branch to the main line. The second area was to open the 1.2 queue of the toolkit and release the new features:

  • ListItem

  • New UbuntuShape rendering properties

  • New Header

Releasing the 1.2 UITK makes the first big iteration of the toolkit development complete.  In the last three cycles the Ubuntu application framework went through three minor Qt upgrades (5.2 - 5.3 - 5.4) and continuously adapted to the improving design and platform.

15.10 - 1.3 release

The upcoming cycle the focus is on convergence. We have shipped a super cool UI Toolkit for touch environment, now it is time to make it offer as complete and as fast toolkit for other form factors and for devices with other capabilities. The emphasis here is on capability. Not only form factor or device mode. The next release (1.3) of the UITK will adopt to the host environment according to its capabilities. Like input capabilities, size and others.

The highlights of the upcoming features:

  • Resolution independence

  • Improve visual rendering (pixel perfectness at any device ratio)

  • Improve performance (CPU and GPU wise)

  • Convergence

    • Tooltips

    • Key navigation - Tab/Shift+Tab

    • Date and Time Pickers

    • Menus

      • Application and

      • context menus

  • Support Sub-theming

  • Support of ListItem expansion

  • Text input magnification on selection

  • Simplified Popovers

  • Text input context menu

  • Deprecate Dialer (Ubuntu.Components.Pickers)

  • Deprecate PopupBase (Ubuntu.Components.Popups)

  • Focused component highlight

  • Support for OSK to keep the focus component above the key rectangle

  • Integrate scope toolkit from Unity with the UI Toolkit

The 1.3 version of the UITK will be the first with the promise that application developers can create both fully functional desktop and phone applications. In practice it means that the runtime UITK will be the same as in the build environment.

16.04 - 2.0 release

Looking forward to our next LTS release our ambition is to polish together all the features and tune the UI Toolkit for the next major release. This edition of the toolkit will serve app developers for long time. The 2.0 will be the “mission completed”.  We expect few features to move from our original 15.10 plans to the 16.04:

  • Clean up deprecated components

  • Rename ThemeSettings to Theme

  • Toolbars for convergence

  • Modal Dialogs

  • Device mode (aka capability) detection

  • Complete scopes support

  • Backend for Alarm services

  • Separate service components from UI components

Read more
Benjamin Zeller

Inner workings of the SDK

From time to time app developers ask how to manually build click packages from their QMake or CMake projects. To understand the answer to that question, knowing about how the SDK does things internally and the tools it uses helps a lot.

First we have to know about the click command. It is one of the most important tools we are about to use, because it provides ways to:

  • create a build environment
  • maintain the build environment
  • execute commands in the build environment
  • build click packages
  • review click packages
  • query click packages

Issuing click --help will show a complete list of options. The click command is not only used on the development machines but also on the device images, as it is also responsible for installing/removing click packages and to provide informations about the frameworks a device has to offer.

Assuming that the project source is already created, probably from a SDK template, and ready to be packed up in ~/myproject, creating a click package requires the following steps:

  1. Create a build target for the device that should be targeted
    click chroot -a armhf -f ubuntu-sdk-15.04 create
  2. Run qmake/cmake on the project to create the Makefiles
    mkdir ~/myproject-build
    cd ~/myproject-build
    click chroot -a armhf -f ubuntu-sdk-15.04 run cmake ../myproject #for cmake
    click chroot -a armhf -f ubuntu-sdk-15.04 run qt5-qmake-arm-linux-gnueabihf ../myproject #for qmake
  3. Run make to compile the project and run custom build steps
    click chroot -a armhf -f ubuntu-sdk-15.04 run make
  4. Run make install to collect all required files in a deploy directory
    rm -rf /tmp/deploy-myproject #make sure the deploy dir is clean
    click chroot -a armhf -f ubuntu-sdk-15.04 run make DESTDIR=/tmp/deploy-myproject install #for cmake
    click chroot -a armhf -f ubuntu-sdk-15.04 run make INSTALL_ROOT=/tmp/deploy-myproject install #for qmake
  5. Run click build on the deploy directory
    click build /tmp/deploy-myproject

We will look into each step at a greater detail and explain the tools behind it starting with:

Creating a build chroot and what exactly is that:

When building applications for a different architecture as the currently used development machine , for example x86 host vs armhf device, cross build toolchains are required. However toolchains are not easy to maintain and it requires a good deal of effort to make them work correctly. So our decision is to use "build chroots" to ease the maintenance of those toolchains. A build chroot is in fact nothing else as the normal Ubuntu you are using on your host machine. Probably its a different version, but it is still coming from the archive. That means we can make sure the toolchains, libraries and tools that are used to build click packages are well tested and receive the same updates as the ones on the device images.

To create a build chroot the following command is used:

click chroot -a armhf -f ubuntu-sdk-15.04 create

Grab a coffee while this is running, it will take quite some time. After the chroot was created for the first time, it is possible to keep it up to date with:

click chroot -a armhf -f ubuntu-sdk-15.04 upgrade

But how exactly does this work? A chroot environment is another complete Ubuntu root filesystem put inside a directory. The "chroot" command makes it possible to treat exactly this directory as the "root directory" for a login shell. Commands running inside that environment can not access the outer filesystem and do not know they are actually inside a virtualized Ubuntu installation. That makes sure your host file system can not be tainted by anything that is done inside the chroot.

To make things a bit easier, /home and /tmp directories are mounted into the chroot. That means those paths are the same inside and outside the chroot. No need to copy files around. But that also means projects can only be in /home by default. It is possible to change that but thats not in the scope of this blog post (hint: check /etc/schroot/default/fstab).

Run qmake/cmake on the project to create the Makefiles

In order to compile the project, CMake or QMake need to create a Makefile from the project description files. The SDK IDE always uses a builddirectory to keep the source clean. That is the recommended way of building projects.

Now that we have a chroot created, we need a way to actually execute commands inside the virtual environment. It is possible to log into the chroot or just run single commands. The click chroots have 2 different modes, one of them is the production mode and one is the  maintenance mode.

Everything that is changed on the chroot filesystem in production mode will be reverted when the active session is closed to make sure the chroot is always clean. The maintenance mode can be used to install build dependencies, but its the job of the user to make sure those dependencies are available on the phone images as well. Rule of thumb is, if something is not installed in the chroot by default it is probably not officially supported and might go away anytime.

click chroot -a armhf -f ubuntu-sdk-15.04 run  #production
click chroot -a armhf -f ubuntu-sdk-15.04 maint #maintenance

Running one of these commands without specifying which command should be executed inside the chroot will open a login shell inside the chroot environment. If multiple successive commands should be executed it is faster to use a login shell, because the chroot is mounted/unmounted every time a session is opened/closed.

For QMake projects usually the IDE takes care of selecting the correct QMake binary, however in manual mode the user has to call the qt5-qmake-arm-linux-gnueabihf in armhf chroots instead of the plain qmake command. The reason for this is that qmake needs to be compiled in a special way for cross build targets and the "normal" qmake can not be used.

Run make to compile the project and run custom build steps

This step does not need much explanations, it triggers the actual build of the project and needs to be executed inside the chroot again of course.

Run make install to collect all required files in a deploy directory

Now that the project build was successful, step 4 collects all the required files for the click package and installs them into a deploy directory. When building with the IDE the directory is located in the current build dir and is named ".ubuntu-sdk-deploy".

It is a good place to check if all files were put into the right place or check if the manifest file is correct.

In order for that step to work correctly all files that should be in the click package need to be put into the INSTALL targets. The app templates in the SDK should give a good hint on how this is to be done.

The deploy directory now contains the directory structure of the final click package.

Run click build on the deploy directory

The last step now is to build the actual click package. This command needs to be executed outside the chroots, simply because of the fact that the click command is not installed by default inside the chroots. What will happen now is that all files inside /tmp/deploy-myproject will be put inside the click package and a click review is executed. The click review will tell if the click package is valid and can be uploaded to the store.

If all went well, the newly created click package should show up in the directory where click was executed, it can now be uploaded to the store or installed on a device.

Read more
Tim Peeters

Return of the Ubuntu UI Toolkit

Next month will be the release of Ubuntu 15.04 (Vivid Vervet) for desktop, and this version of Ubuntu will soon become the version that will be installed on Ubuntu phones as well. With the release of 15.04, we also release a new version of our UI toolkit: Ubuntu.Components 1.2. Below are some of the new features that it will have.

Hasta la vista, toolbar!

In Ubuntu.Components 1.1, the bottom-edge toolbar was replaced by a new header that can be used for navigating the app and trigger actions. Actions that used to be in the  toolbar were automatically moved to the header, and a useDeprecatedToolbar property was added to the MainView for developers that liked to keep the toolbar. In 1.2, the toolbar and useDeprecatedToolbar property are definitely gone which enabled us to clean up the MainView and header code, so that we can give you a fresh new visual design and more control over the looks and behavior of the header very soon.

One ListItem to rule them all

ListItem leading actions

There are many different list items in Ubuntu.Components.ListItems, but they are not always easy to customize and the performance when you use thousands of them in your app is not optimal. Therefore, we now introduce the all-new ListItem component. It replaces all of the old list items, is super-fast (even when you have ten thousands of them), you can swipe them left and right to reveal actions, they offer selection mode (to quickly select a subset of all the list items), and the user can re-order the items in a list. Awesome :)


Ubuntu Shape up (doo doo doo)

Image with transparent background in UbuntuShape

The UbuntuShape is now in the best shape ever! It has been refactored to optimize performance (for example, the rendering is now "batched" so even a lot of them can be rendered fast), semi-transparent images and colored backgrounds are supported, you can use all the fill modes and tiling that the Image component supports, there is 2D transformation support, and the implementation was made extensible so that new features can be added more easily.

Here is the code for the app that was used for the two screenshots above:

import QtQuick 2.4
import Ubuntu.Components 1.2

MainView {
    //useDeprecatedToolbar: false // terminated

    Page {
        title: "Return of the UITK"

        ListItemActions {
            id: exampleLeadingActions
            actions: [
                Action {
                    iconName: "tick"
                Action {
                    iconName: "delete"

        ListView {
            anchors.fill: parent
            model: 10
            delegate: ListItem {
                id: listItem
                Label {
                    anchors {
                        left: parent.left
                        verticalCenter: parent.verticalCenter
                    text: "List item "+index
                leadingActions: exampleLeadingActions

                UbuntuShape {
                    anchors {
                        right: parent.right
                        bottom: parent.bottom
                    backgroundMode: listItem.highlighted ?
                                        UbuntuShape.VerticalGradient :
                    backgroundColor: listItem.highlighted ?
                    source: Image {
                        source: "logo.png"
                    sourceFillMode: UbuntuShape.PreserveAspectFit

Besides these new features, we fixed a whole bunch of bugs and we are working hard on the next version of the UI toolkit that we will be blogging about in the near future, so stay tuned for more good stuff!


Read more
Zoltán Balogh

So if you are new to QtCreator the first thing that freaks you out will be the concept of Kits. Yes it does look complicated, big and you might want to ask why do I need this.

Right, let’s take few steps back and look at the bigger picture.

Most programmers start their hobby or carrier with basic (not that one) pc programming. You have the compiler and libraries on your machine, you start hacking around with your code and once you think it will pass at least the syntax check you go to the terminal, compile the code and be happy when you see the binary executable. If it runs without segfaults then you start to gain confidence and you are the happiest kid on Earth once the program does what you coded it for.

That is a fairly simple and common scenario, still it has all the components what actually make an SDK. And i guess you know that in the SDK, the K stands for Kit.

Let’s continue with this thinking. You want to show the program to your friends. That is nothing strange, even coders are social beings. If your program is using dynamically linked libraries from the system then your friends need a bit of luck to have the very same system libraries on their machine as you have on yours. Not to mention that you compiled your program for one specific processor architecture and nothing guarantees that your friends have the same architecture as you had.

So, we are safe and good as long our program stays on our computer but trouble with libraries, binary compatibility and processor architecture will pop up when we want to move our program around without recompiling it again. And imagine, we are still talking about PC to PC porting. Let’s raise the bar.

How does it go when you want to write an application for a mobile device? Most likely your computer is an x86 based PC and these days most mobile devices have some sort of ARM processor. So, here we go, our native local compiler what made us so happy just few paragraphs back is now obsolete and we will need a compiler what can produce an ARM binary for the specific device. It could be armv6, armv7 or whatever exotic ARM processor your target device is built with. Good, we now have a compiler but our code is still using a bunch of libraries. In the Ubuntu world and specially with the ultimate convergence on our roadmap this part of the story is a bit easier and will get even better soon. But still if your PC is running the LTS Ubuntu release (14.04 right now) you do not necessarily expect the same libraries and header files being present on your machine as on a target device what is on 15.04 or even newer.

I guess at this point many would say with a disappointed tone that after you learned that your good old compiler is obsolete now all your locally installed development libraries and header files are useless too. Think of Borat saying “nice”.

Okay, so we are left without compiler, libraries and header files. But they should come from somewhere, right?

And that is where the Kits come into the picture. The official definition of the QtCreator Kits sure sounds a bit academic and dry, so let’s skip it. In short, Kits are the set of values that define one environment, such as a device, compiler, Qt version, debugger command, and some metadata.

I love bicycling so I use cycling analogies whenever it is possible. Imagine that you are in the mood to have a ride downhill in the forest. You will take your mountain bike, knee and elbow pad, lots of water, some snacks and your clothes what take dirt better, a massive helmet and your camera. If you just cycle to your office you take your city bike, lighter helmet and you put on regular street wear. Different target, different set of equipment. How cool it would be just to snap your finger and say out loud “ride to the city”  and all the equipment would just appear in front of you.


That is exactly what happens when you have Kits set up in your QtCreator and you are building your application for and running them on different targets.

QtCreator is an IDE and developers who choose to work with IDEs do expect a certain level of comfort. For example we do not want to resolder and rewire our environment just because we want to build our project for a different target. We want to flip a switch and expect that the new binaries are made with a different compiler against a different set of libraries and headers. That is what QtCreator’s target selector is for. You simply change from the LTS Desktop Kit to the 15.04 based armhf target and you have a whole different compiler toolchain and API set at your service.

At this point Kits looks pretty and easy. You might ask what is the catch then. Why IDEs and SDKs do not come with such cool and well integrated Kits? Well there is a price for every cool feature.  At this moment each Kit in ready for action state is about 1.7GB. So kits are big and the SDK does not know what Kits you want to use. What means is that if we want to install all kits you might use the SDK would be 8-10GB easily.

Why kits are so big and can they be made smaller?

That is a fair question I got very often. First of all, the kits are fully functional chroots in the case of the Ubuntu SDK. It means that other than the compiler toolchain we have all the bells and whistles one needs when entering a chroot. Just enter the click chroot and issue the dpkg -l command to see that yes, we do have a full blown Ubuntu under the hood. In our SDK model the toolchain and the native developer tools live in the click chroots and these chroots are bootstrapped just as any other chroot. It means that each library, development package and API is installed as if it were installed on a desktop Ubuntu. And that means pulling in a good bunch of dependencies you might not need ever. Yes, we are working on making the Kits smaller and we are considering to support static kits next to the present dynamic bootstrapped kits.

Alright, so far we have covered what Kits are, what they contain. The most important question is do you need to care about all of these? Do you need to to configure and set up these kits yourself. Luckily the answer to these questions is no.

In the Ubuntu SDK these Kits are created on the first start of the SDK and set up automatically when a new emulator is deployed or a new device is plugged in. Of course you can visit the builder chroots under the Ubuntu and Build & Run sections in the dialog what opens with the Tools->Options… menu. But most of the application developers can be productive without knowing anything about these. Of course understanding what they are is good and if you are into development tools and SDKs then it is fun to look behind the curtains a bit.

Read more