Canonical Voices

Posts tagged with 'english'

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
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
David Planella

Ubuntu Online Summit
The 15.04 release frenzy over, but the next big event in the Ubuntu calendar is just around the corner. In about a week, from the 5th to 7th of May, the next edition of the Ubuntu Online Summit is taking off. Three days of sessions for developers, designers, advocates, users and all members of our diverse community.

Along the developer-oriented discussions you’ll find presentations, workshops, lightning talks and much more. It’s a great opportunity for existing and new members to get together and contribute to the talks, watch a workshop to learn something new, or ask your questions to many of the rockstars who make Ubuntu.

While the schedule is being finalized, here’s an overview (and preview) of the content that you should expect in each one of the tracks:

  • App & scope development: the SDK and developer platform roadmaps, phone core apps planning, developer workshops
  • Cloud: Ubuntu Core on clouds, Juju, Cloud DevOps discussions, charm tutorials, the Charm, OpenStack
  • Community: governance discussions, community event planning, Q+As, how to get involved in Ubuntu
  • Convergence: the road to convergence, the Ubuntu desktop roadmap, requirements and use cases to bring the desktop and phone together
  • Core: snappy Ubuntu Core, snappy post-vivid plans, snappy demos and Q+As
  • Show & Tell: presentations, demos, lightning talks (read: things that break and explode) on a varied range of topics

Joining the summit is easy, you’ll just need to follow the instructions and register for free to the Ubuntu Online Summit >

UOS highlights: back to the desktop, snappy and the road to convergence

This is going to be perhaps one of the most important summits in recent times. After a successful launch of the phone, followed by the exciting announcement and delivery of snappy Ubuntu Core, Ubuntu is entering a new era. An era of lean, secure, minimal and modular systems that can run on the cloud, on Internet-enabled devices, on the desktop and virtually anywhere.

While the focus on development in the last few cycles has been on shaping up and implementing the phone, this doesn’t mean other key parts of the project have been left out. The phone has helped create the platform and tools that will ultimately bring all these projects together, into a converged code base and user experience. From desktop to phone, to the cloud, to things, and back to the desktop.

The Ubuntu 15.10 cycle begins, and so does this exciting new era. The Ubuntu Online Summit will be a unique opportunity to pave the road to convergence and discuss how the next generation of the Ubuntu desktop is built. So the desktop is back on the spotlight, and snappy will be taking the lead role in bringing Ubuntu for devices and desktop together. Expect a week of interesting discussions and of thinking out of the box to get there!

Participating in the Ubuntu Online Summit

Does this whet your appetite? Come and join us at the Summit, learn more and contribute to shaping the future of Ubuntu! There are different ways of taking part in the online event via video hangouts:

  • Participate or watch sessions – everyone is welcome to participate and join a discussion to provide input or offer contribution. If you prefer to take a rear seat, that’s fine too. You can either subscribe to sessions, watch them on your browser or directly join a live hangout. Just remember to register first and learn how to join a session.
  • Propose a session – do you want to take a more active role in contributing to Ubuntu? Do you have a topic you’d like to discuss, or an idea you’d like to implement? Then you’ll probably want to propose a session to make it happen. There is still a week for accepting proposals, so why don’t you go ahead and propose a session?

Looking forward to seeing you all at the Summit!

The post Announcing the next Ubuntu Online Summit appeared first on David Planella.

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
David Planella

Nearly two years ago, the Ubuntu Community Donations Program was created as an extension to the donations page on, where those individuals who download Ubuntu for free can choose to support the project financially with a voluntary contribution. In doing so, they can use a set of sliders to determine which parts of the project the amount they donate goes to (Ubuntu Desktop, Ubuntu for phone, Ubuntu for tablet, Ubuntu on public clouds, Cloud tools, Ubuntu Server with OpenStack, Community projects, Tip to Canonical).

While donations imply the trust from donors that Canonical is acting as a steward to manage their contributions, the feedback from the community back then was that the Community slider required a deeper level of attention in terms of management and transparency. With community being such an integral part of Ubuntu, and with the new opportunity to financially support new community projects, events or travel, it was just logical to ensure that the funds allocated to them were managed fairly and transparently, with public reporting every six months and a way for Ubuntu members to request funding.

Although the regular reports already provide a clear picture where the money donated for community projects is spent on, today I’d like to give an update on the bigger picture of the Community Donations Program and answer some questions community members have raised.

A successful two years

In a nutshell, we’re proud to say that the program continues to successfully achieve the goals it was set out for. Since its inception, it has given the ability to fund around 70,000 USD worth of community initiatives, conferences, travel and more. The money has always been allocated upon individual requests, the vast majority of which were accepted. Very few were declined, and when they were, we’ve always strived to provide good reasoning for the decision.

This process has given the opportunity to support a diverse set of teams and projects of the wide Ubuntu family, including flavours and sponsoring open source projects and conferences that have collaborated with Ubuntu over the years.

Program review and feedback

About two years into the Program, we felt a more thorough review was due: to assess how it has been working, to evaluate the community feedback and to decide if there are any adjustments required. Working with the Community Council on the review, we’ve also tried to address some questions from Ubuntu members that came in recently. Here is a summary of this review.

The feedback in general has been overwhelmingly positive. The Community Donations Program is not only seen as an initiative that hugely benefits the Ubuntu project, but also the figures and allocations on the reports and are a testament to this fact.

Criticism is also important to take, and when it has come, we’ve addressed it individually and updated the public policy or FAQ accordingly. Recently, it has arrived in two areas: the uncertainty in some cases where the exact cost is not known in advance (e.g. fluctuating travel costs from the date of the request until approval and booking) and the delay in actioning some of the requests. In the first case, we’ve updated the FAQ to reflect the fact that there is some flexibility allowed in the process to work with a reasonable estimate. In the second, we’ve tried to explain that while some requests are easy to approve and actioned in a matter of a few days (we review them all once a week), some others take longer due to several different factors: back and forth communication to clarify aspects of the requests, the amount of pending requests, and in some cases, the complexity of arranging the logistics. In general, we feel that it’s not unreasonable to expect sending a request at least a month in advance to what it is being planned to organize with the funds. We’re also making it clear that requests should be filled in advance as opposed to retroactively, so that community members do not end up in a difficult position should a request not be granted.

One of the questions that came in was regarding the flavour and upstream donation sliders. Originally, there were 3 community-related sliders on 1) Community participation in Ubuntu development, 2) Better coordination with Debian and upstreams, 3) Better support for flavours like Kubuntu, Xubuntu, Lubuntu. At some point during the 14.04 release sliders 2) and 3) were removed, leaving 1) as Community projects. Overall, this didn’t change the outcome of community allocations: since its beginning, the Community Donations Programme amounts have only come from the first slider, which is what the Canonical Community team are managing. From there, money is always allocated upon request fairly, not making a difference and benefiting Ubuntu, its flavours and upstreams equally.

All that said the lack of communication regarding the removal of the slider was something that was not intended and should have been communicated with the Community Team and the Community Council. It was a mistake for which we need to apologize. For any future changes in sliders that affect the community we will make sure that the Community Council is included in communications as an important stakeholder in the process.

Questions were also raised about the reporting on the community donations during the months in 2012/2013, between the donations page going live and the announcement of the Community Donations Program. As mentioned before, the Program was born out of the want to provide a higher level of transparency for the funds assigned to community projects. Up until then (and in the same way as they do today for the rest of the donation sliders) donors were trusting Canonical to manage the allocations fairly. Public reports were made retroactively only where it made sense (i.e. to align with fiscal quarters), but not going back all the way to the time before the start of the Program.

All in all, with these small adjustments we’re proud to say we’ll continue to support community projects with donations in the same way we’ve been doing these last two years.

And most especially, we’d like to say a big ‘thank you’ to everyone who has kindly donated and to everyone who has used the funds to help shaping the future of Ubuntu. You rock!

The post The Ubuntu Community Donations Program in review appeared first on David Planella.

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
Zsombor Egri

Creating a theme for your application

The theming engine is one of the least documented features of Ubuntu UI Toolkit. While we are preparing to create the third generation theming engine, which will support sub-theming and runtime palette color customizations, there are more and more app developers asking about how to create their own theme for the application itself. There were also questions on how to create a shared theme so other applications can use these themes. But let’s get first the application theming.

The application themes are application specific, and should be located in the application’s installation folder. They can derive from a pre-defined system theme (Ambiance or SuruDark) as well as be standalone themes, not reusing any system defined themes. However this latest one is not recommended, as in this case you must implement the style of every component, which in one way requires lot of work, and secondly it uses few APIs which are not stable/documented.

Assuming the theme is located in a separate folder called MyTheme, the second step would be to create a file called “parent_theme” where you put the URI of the theme your application theme derives from. Your parent_theme would look like

// parent_theme

Now, let’s change some palette values. The way to do that is to create a Palette.qml file, and override some values you want.

// Palette.qml

import QtQuick 2.4
import Ubuntu.Components 1.2
import Ubuntu.Components.Themes.SuruDark 1.1 as SuruDark

SuruDark.Palette {
    normal.background: “#A21E1C”
    selected.backgroundText: “lightblue”

If you want to change some component styles, you have to look into the parent theme and check the style component you want to change. It can be that the parent theme doesn’t have the style component defined, in which case you must follow its parent theme, and search for the component there. This is the case if you want to change the Button’s style, SuruDark theme doesn’t have the style component defined, therefore you must take the one from its parent, Ambiance. So the redefined ButtonStyle would look like:

// ButtonStyle.qml

import QtQuick 2.4
import Ubuntu.Components 1.2

// Note: you must import the Ambiance theme!
import Ubuntu.Components.Themes.Ambiance 1.1 as Base

Base.ButtonStyle {
    // Let’s override the default color

For now only a few style component is exported from the two supported system themes, in case you see one you’d like to override just file a bug. Then there are only a handful of style APIs made stable, therefore overriding the non-documented styles may be dangerous, as their API may change. The stable style APIs are listed in Ubuntu.Components.Styles module and their implementation and unstable APIs are in Ambiance and SuruDark themes.

And finally you can load the theme in the application as follows:

// main.qml

import QtQuick 2.4
import Ubuntu.Components 1.2

MainView {
    // Your code comes here

    // Set your theme
    Component.onCompleted: = “MyTheme”


That’s it. Enjoy your colors!

P.S. A sample code is available here.

Read more
David Callé

Announcing the Ubuntu Porting guide 2.0

In the last few weeks, Ubuntu has reached a major milestone with the first flash sales of the BQ Aquarius - Ubuntu Edition. This is only the beginning of seeing Ubuntu on a wider selection of phones and tablets, and thanks to an incredibly enthusiast porting community, more devices have been part of that show. Some of these skilled porters have even set up their own image server to provide updates over-the-air!

To ease the porting process, the Porting Guide has been updated to reflect the current procedure of enabling new devices. From setting up your dev environment, to configuring the kernel and debugging AppArmor, it covers the main points of making a fully working port. Currently focusing on AOSP ports, it will be extended in due time to detail CyanogenMod-specific processes.

If you are interested in porting, please make sure you provide feedback on any issues and roadblocks that could arise, either on Launchpad or on the ubuntu-phone mailing-list.

Thank you and good work, fellow devices adventurers!

Read more
David Planella

This is a guest post from Jordi Allue, Senior SW Architect at Tuso technologies
In September 2014, Ubuntu invited Tuso Technologies to be one of the first Ubuntu Phone OS developers with a version of Fiabee’s Cloud-Mobile Collaboration, Synchronisation and Sharing App for the new Ubuntu Phone OS. We jumped at the opportunity because it was in line with Tuso Technologies’ cross-platform compatibility strategy and found it to be an interesting challenge. The process was far simpler and faster than we originally expected, and the results exceeded our expectations.

Fiabee is a carrier-grade, enterprise caliber, cloud-mobile Collaboration, Synchronization and Sharing Software-as-a-Service (SaaS). With Fiabee, Telecom Operators, Internet Service Providers and other Managed Service Providers generate new revenues and reduce churn by taking market share away from large OTT App (Over The Top Application) providers.

Ubuntu Phone Apps are created natively or in HTML5 within a WebApp. Fiabee’s existing HTML5 app, which includes CSS3 and Javascript, was the ideal match for Ubuntu Phone.

We started the process by installing Ubuntu’s Software Development Kit (SDK) and making ourselves familiar with it. The installation was straight forward with a simple "apt-get install ubuntu-sdk" instruction. Although we had no prior experience with Ubuntu’s Integration Development Environment (IDE), based on Qt Creator, the tutorials available on Ubuntu’s website helped us create our first HTML5 trial app. Next we tested the app directly on an Ubuntu Phone, getting familiar with Ubuntu’s Operating System (OS) and IDE was the most challenging of the tasks. That said, it only took us a few days to prepare the infrastructure to develop our own app. For those who don’t have an Ubuntu Phone, Ubuntu’s SDK provides a mobile device emulator.

From there on, it was easy to adapt Fiabee’s web application to Ubuntu’s environment. With the help of the SDK instructions and manuals, we integrated the Web app into the development project, ran it on the device and created the deployment package. After configuration, we adapted the visual appearance and operation to Ubuntu’s standards.

We were amazed to find that the functions of Fiabee’s App which are often difficult to adapt were almost automatic with Ubuntu Phone, such as accessing the phone’s file system, interacting with third party Apps or opening documents downloaded from the cloud. This demonstrates that Ubuntu OS is truly “open”. During the last steps of creating the package and uploading it to the Ubuntu App Directory, we had a minor problem with the definition of the App’s security policies but that was quickly resolved with the help of Ubuntu’s App Directory Tech Support team.

From our perspective, bringing Fiabee to Ubuntu Phones was a piece of cake. It was a quicker and an easier experience than we’ve had with other platforms, despite it being new and notably different from the others with its App interaction menu. We were able to carry over all the functionalities of the Fiabee App without losing any, as was the case with other platforms, and without having to invest re-development time. It was as simple as tweeking Fiabee’s existing web app. With Fiabee’s App for Ubuntu Phones, we continue to deliver a good user experience to Fiabee users with a further extended range of mobile devices with which to access our service.

About Tuso technologies SL. Founded in late 2008, with offices in Barcelona, Spain, and Palo Alto, USA, Tuso Technologies develops carrier-grade, enterprise-caliber, cloud-mobile Value-Added-Services (VAS), including Fiabee, Locategy & Open API, selected by leading Mobile Network Operators, ISV and corporations such as Telefonica (Movistar), France Telecom (Orange) , Ono (Vodafone), R Cable, Panda Security, Applus+ among others.

Read more
Victor Palau

Not long back Chris Wayne published a post about a scope creator tool.  Last week, I was visiting bq and we decided with Victor Gonzalez  that we should have a scope for Canal bq. The folks at bq do an excellent job at creating “how to” and “first steps” videos, and they have started publishing some for the bq Aquaris E4.5 Ubuntu Edition.

Here is a few screenshots of the scope that is now available to download from the store:


The impressive thing is that it took us about 5 min to get a working version of the scope.  Here is what needed to do:

  • First, we followed Chris’ instructions to install the scope creator tool.
  • Once we had it set up on my laptop, we run:
    scopecreator create youtube com.ubuntu.developer.victorbq canalbq
    cd canalbq
  • Next, we configured the scope. The configuration is done in a json file called manifest.json. This file describes the content of what you will publish later to the store. You need to care about: “title”, “description”, “version” and “mantainer”. The rest are values populated by the tool:
    scopecreator edit config
    "name": "com.ubuntu.developer.victorbq.canalbq",
    "description": "Canal bq",
    "framework": "ubuntu-sdk-14.10",
    "architecture": "armhf",
    "title": "Canal bq",
    "hooks": {
    "canalbq": {
    "scope": "canalbq",
    "apparmor": "scope-security.json"
    "version": "0.3",
    "maintainer": "Victor Gonzalez <>"
  • The following step was to set up the branding: Easy! Branding is define on an .ini file. “Display name” will be the name listed on the “manage” window once installed, and also will be the title of your scope if you don’t use a “PageHeader.Logo”. the [Appearance] section describes the colours and logos to use when banding a scope.
    scopecreator edit branding
    DisplayName=Canal bq
    Description=Youtube custommized channel
    Author=Canonical Ltd.
  • The final part is to define the departments (drop down menu) for the scope. This is also a json file and it is unique the youtube scope template. You can either use “playlists” or “channels” (or both) as departments. The id PLjQOV_HHlukyNGBFaSVGFVWrbj3vjtMjd corresponds to a play list from youtube, with url=
    scopecreator edit channels{
    “maxResults”: “20”,
    “playlists”: [
    “id”: “PLjQOV_HHlukyNGBFaSVGFVWrbj3vjtMjd”,
    “reminder”:”Aquaris E4,5 Ubuntu Edition”
    “id”: “PLjQOV_HHlukzBhuG97XVYsw96F-pd9P2I”,
    “reminder”: “Tecnópolis”
    “id”: “PLC46C98114CA9991F”,
    “reminder”: “aula bq”
    “id”: “PLE7ACC7492AD7D844”,
    “reminder”: “primeros pasos”
    “id”: “PL551D151492F07D63”,
    “reminder”: “accesorios”
    “id”: “PLjQOV_HHlukyIT8Jr3aI1jtoblUTD4mn0”,
    “reminder”: “3d”

After this, the only thing left to do is replace the placeholder icon, with the bq logo:
And build, check and publish the scope:
scopecreator build

This last command generates the click file that you need to upload to the store. If you have a device (for example a Nexus4 or an emulator ), it can also install it so you can test it. If you get any issues getting the scope to run, you might want to check your json files on It is a great web tool that will help you make sure your json doc is ship shaped!

It is super simple to create a scope for a youtube channel! so what are you going to create next?

Read more
David Planella

Announcing the Scope Showdown winners

We're thrilled to announce the results of the Ubuntu Scope Showdown: a contest to develop a scope in 6 weeks and win exciting prizes. Fleshing out Ubuntu's innovative take at the content and services experience, participants had the opportunity to use the new development tools to create a complete scope from scratch and publish it to the store in just a few weeks.

Contest submissions were reviewed by an international panel of judges including Canonical employees and members of the wider Ubuntu community:

The winner is: Cinema scope

The Cinema Scope by Daniele Laudani is the winner of this Scope Showdown edition. Daniele's scope scored the best judge ratings for its visual appeal, usability, general interest and use of scope features. To him goes the Dell XPS 13 developer laptop preloaded with Ubuntu. Enjoy!

Outstanding runner ups

The quality of all winning scopes was impressive, which resulted in a draw in some of the runner ups. In the end, rather than a tie break, we decided to include an extra prize as a recognition to their outstanding work. And without further ado, we're proud to present the additional winners.

Discerning Duck

Riccardo Padovani, of Ubuntu Core Apps fame, takes home with the Discerning Duck scope the Logitech UE Boom Bluetooth speakers, compatible with the Ubuntu phone.


Developer Bogdan Cuza, with the Mixcloud scope scores a Nexus 7 tablet running Ubuntu with all winner scopes preinstalled.


Sam Segers, with the Places scope, is the winner of an Ubuntu bundle, including:

  • An Ubuntu messenger bag
  • An Ubuntu infographic T-shirt
  • An Ubuntu neoprene laptop sleeve

RSS Feeds

Matthew Jump, with the RSS Feeds scope also wins an Ubuntu bundle including:

  • An Ubuntu backpack
  • An Ubuntu Circle of Friends Dot Design T-shirt
  • An Ubuntu Neoprene Laptop Sleeve

Your Shot

Kunal Parmar, another Core App Developer, wins with the Your Shot scope yet another Ubuntu bundle:

  • An Ubuntu backpack
  • An Ubuntu Circle of Friends Dot Design T-shirt
  • An Ubuntu Neoprene Laptop Sleeve

Scopes everywhere

Congratulations to all winners, and to all participants: everyone did a fantastic job. Given the early adoption of scopes and developer tools, judges and reviewers were particularly impressed by the quality of the submissions.

Remember you can install any of the winner scopes and more from the Ubuntu Software Store. It's now time to start thinking beyond the apps grid and bringing interesting scopes that enable Ubuntu phone users to get the data that matters to them. Looking forward to seeing scopes everywhere!

Get started writing a scope today >

Read more
Michael Hall

The 5 weeks after the Ubuntu Scopes Showdown announcement are coming to an end, it's time to start putting the pencils down and submitting your scopes for the judges to do their reviews. While you've still got two days to fix some bugs and do some final polish, the 3rd of December is the last day for submissions to be accepted for the Showdown. Remember that to qualify, you'll need to:

Register your scope for the contest

Submit your scope to the Ubuntu Software Store

Registering your scope

To register your scope for the judges' review, you'll simply need a couple of minutes to fill in the registration form. It might be worth filling it in advance, even if you are planning to upload your app at the last minute. You can submit the form now and still upload new revisions of your app until the 3rd of December. Register your scope for participation


Submitting your scope

Submitting your scope to the store should also be quick and easy. The upload workflow is exactly the same as for apps, and with automated reviews it takes just a few minutes from upload to your scope being available for everyone on the Ubuntu Software Store. To ensure your scope is discoverable and looks good, you might want to check out the scope upload tips › And when you're ready to start the upload, you can follow the 5-step process to get it published ›

Need help?

If you need help with any of the above, feel free to reach out in any of the channels below:

The Ubuntu App Developers IRC channel

The Ubuntu App Showdown subreddit

The Ubuntu App Developers G+ community

Looking forward to seeing your scopes in the store!

Read more
David Callé

Now that your scope is in a working state, it’s time to get it ready for publication. In this tutorial you will learn how to make your scope look good when the user is browsing the store or the list of scopes installed on the phone.
In the next steps, we are going to prepare a few graphics, edit the <scope>.ini file located in the data directory of your project and package the scope for the store.



Read more
David Planella

Over a week ago, we announced the Ubuntu Scope Showdown: a competition to write a scope for Ubuntu on phones in 5 weeks and win exciting prizes.

Scopes are Ubuntu’s innovative take at revolutionizing the content and services experience. For users, they provide quick and intuitive access to content without the need of loading an app. For developers and operators, scopes provide an easy path to surface their content and customize the UX in a way that is very flexible and integrated.

After the initial contest kickoff, we’ve already had a number of participants blogging, sharing updates and teasers about their work. Here’s a peek at some of their progress.

A variety of scopes

In the words of Robert Schroll, of Beru fame, e-mail apps are just passé. So much that he decided to explore an interesting concept: reading your e-mail with a scope. With a nice extra touch: Ubuntu Online accounts integration.

 Because e-mail apps are so 90s - the Gmail scope

Because e-mail apps are so 90s – the Gmail scope

After listening to one of Daniel Holbach’s mixes, Bogdan Cuza thought they alone deserve a scope, and so the Mixcloud scope was born. The rest, as they say, is history.

Can't get enough of those Balkan Beats - the Mixcloud scope

Can’t get enough of those Balkan Beats – the Mixcloud scope

You don’t know where to eat tonight? No worries, Sam Segers has you covered. Check out his Google places scope to easily find somewhere new to go.

Your cooking skills not up to your date's expectations? The Google places scope comes to the rescue

Your cooking skills not up to your date’s expectations? The Google places scope comes to the rescue

Developer Dan has a treat for all of us movie lovers: the Cinema scope. Features categories and departments, with settings, TV series and genres coming up soon! Check out the details on his blog.

Helping Ubuntu users see what stuff dreams are made of since 2014 - the Cinema scope

Helping Ubuntu users watch stuff dreams are made of since 2014 – the Cinema scope

Riccardo Padovani is bringing the dark horse -or well, duck?- of search engines into Ubuntu. Armed with the DuckDuckGo scope, get results like a pro with “real privacy, smarter search and less clutter”.

Duck is the new black - the DuckDuckGo scope

Duck is the new black – the DuckDuckGo scope

A wishlist of scopes

As Alan Pope and Michael Hall, I do have my wishlist of scopes for content that I’d like to have accessible at a flick of the finger on my phone. Maybe someone of you can make our day?

  • 8tracks scope: I love music, and I love mixes. 8tracks is a music streaming service to listen to the mixes their community members create and to get creative submitting mixes. As an avid mixer and listener, I’d be using this all of the time, especially if it came with Online Accounts integration that showed me content relevant to my interests.
  • Ask Ubuntu scope: the biggest Ubuntu Q&A site. I regularly check the ‘application-development‘ tag there to see any new questions and if I can help a fellow Ubuntu developer (and you should too). It’d be absolutely awesome to get those updates easily on my phone screen, with settings to filter on tags and the ability to upvote/downvote questions and answers.

Not sure what to write a scope for yet? Well, check out the ideas over at the Showdown reddit, or let your imagination run wild with a comprehensive list of APIs to get more inspiration!

A prize for your scopes

It’s not too late to enter the Showdown, you too can write a scope and win prizes! Here are some tips to get started:

Looking forward to seeing the next batch of scopes participants come up with!

The post The Ubuntu Scope Showdown – progress showcase appeared first on David Planella.

Read more
David Planella

As part of the Ubuntu App Developer Week, I just ran a live on-air session on how to internationalize your Ubuntu apps. Some of the participants on the live chat asked me if I could share the slides somewhere online.

So here they are for your viewing pleasure :) If you’ve got any questions on i18n or in Ubuntu app development in general, feel free to ask in the comments or ping me (dpm) on IRC.

The video

The slides


The post Internationalizing your apps at the Ubuntu App Developer Week appeared first on David Planella.

Read more
David Planella

A sample of the wider Ubuntu Community team, with Canonicalers and volunteer core app developers

A sample of the wider Ubuntu Community team, with Canonicalers and volunteer core app developers

After the recent news of Jono stepping down as the Ubuntu Community Manager to seek new challenges at XPRIZE, a new era in Ubuntu begins. Jono’s leadership, passion and drive to continually push the boundaries have been contagious over the years, and have been the catalyst for growing the unique community of individuals that defines Ubuntu today.

Jono is now joining the ranks of non-Canonical Ubuntu members, and while this will change the angle of participation, I’m certain that it won’t change his energy and dedication one bit. But most importantly, it’s a testament to his work that his former team will continue to thrive and take up the torch in pushing those boundaries.

For us, it will be business as usual in the sense of implementing our roadmap, continuing to grow a strong and open community, being innovative in how we do it, and coordinating the logistics around our plans. So not much will be different in that regard, but obviously some organizational bits will change.

As part of the transition, the Ubuntu Community Team at Canonical in full, that is, Michael Hall, Daniel Holbach, Alan Pope, Nicholas Skaggs and myself, will now be hosting the weekly Ubuntu Q&A, starting today at 18:00 UTC on Ubuntu On Air (click here for the time at your location).

The Ubuntu Community Team Q&A

Openness, both in being a transparent and welcoming community, is one of the core values of Ubuntu, and we believe the channels should be always open for a healthy information flow and to help contributors get involved.

As such, the Ubuntu Community Team Q&A will continue to provide a weekly, 1-hour-long session open for participation to anyone who wants to ask their questions about Ubuntu. In fact, as in former editions, you can ask the Community Team just anything about Free Software, Technology, or whatever you come up with. As before, the only questions we won’t answer are those related to technical support, where you’ll be much better served using Ask Ubuntu, the Ubuntu forums or IRC.

Join the Ubuntu Community Team Q&A at 18:00 UTC today and ask your questions >

The Ubuntu Online Summit is coming soon!

Also, following the thread of events and participation, the new Ubuntu Online Summit (UOS) is coming up very soon, and it’s an excellent opportunity to learn about getting involved in Ubuntu, organizing or presenting the plans of the different Ubuntu teams for the next months.

UOS will be held on June 10th – 12th and it will be a combination of the former Ubuntu Developer Summit and the more user-facing events we’ve been organizing in the past. This opens the door to a wider audience that can follow a richer mix of developer and user or contributor content.

If you want to learn about the details, check out Michael’s UOS post on how it’s going to work. If you want to contribute and make a difference in Ubuntu, do register a session too!

Looking forward to seeing you soon!

The post A new era for the Ubuntu community team, or business as usual appeared first on David Planella.

Read more