Canonical Voices

Posts tagged with 'article'

Benjamin Zeller

or: here comes LXD

The next iteration of the Ubuntu SDK IDE

or: here comes LXD

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

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

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

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

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

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

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

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

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

Get started

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

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

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


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

Known issues and troubleshooting

The lxd group membership

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

sudo useradd -G lxd `whoami`

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

Reset QtCreator settings

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

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

Clean up old click chroots

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

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

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

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

$ mount|grep schroot

NVIDIA video driver

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

Check if you have a backup graphics card

$ sudo lshw -class display

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

$ sudo prime-select intel

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

$ sudo apt-get remove bumblebee

$ sudo apt-get install nvidia-prime

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

Let start the new IDE

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

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

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

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

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

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

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

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

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

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

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

We can use the default naming for the kits.

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

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

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

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

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

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

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

After finishing the wizard the IDE will open up



Read more
David Callé

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

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

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

Install Snapcraft

On Ubuntu

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

sudo apt update
sudo apt install snapcraft

On other platforms

Get the Snapcraft source code ›

Craft your snaps!

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

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

What’s next?

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

Read more
Daniel Holbach

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

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

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

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

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

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

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

Read more
David Callé

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

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


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

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

Landed in the playpen:

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

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

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

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

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

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

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

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

Read more
Daniel Holbach

Announcing the Snappy Playpen

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

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

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

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

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

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

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

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

Read more
liam zheng

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

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


Wifi Display:点击观看

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



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



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



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



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



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

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

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

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

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

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

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

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

Read more
Zoltán Balogh

Can I haz MainView in a Window?

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

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

So what can we do now?

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

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

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

A challenger appears

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

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

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

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

Read more
Zoltán Balogh

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

Let’s start with  the background story.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read more
liam zheng






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

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


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

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

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

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

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

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

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



Read more
Christian Dywan

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

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

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

Remember OTA-10 and framework 15.04.4?

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

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


Read more
liam zheng

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

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

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

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

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

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

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

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

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

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

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

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

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


Read more
liam zheng




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

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


Read more
liam zheng


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

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

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

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

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

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

LimeSDR Crowd Supply 宣传视频(优酷)

Read more
April Wang

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

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

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

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

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

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

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

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

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

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

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

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

Read more
Community Team

The squirrel has landed!

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

Ubuntu 16.04 LTS is here!

Software distribution

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

Ubuntu Core and Snapcraft

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

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

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

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

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

Phone and Tablet

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

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

  • Re-designed Out Of the Box Experience

  • VPN support

  • Easy switching to desktop mode

  • New colour palette

  • New default apps: uNav, Dekko, Calendar

For more, see the release notes.

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

Community phone ports

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

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

Developer portal

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

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

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

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

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

Community and planning

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

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

Read more
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