Canonical Voices

Posts tagged with 'english'

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!

People

Along with the usual #snappy IRC channel on Freenode, we used gitter.im 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
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"
    minimumWidth: units.gu(30)
    minimumHeight: units.gu(50)
    maximumWidth: units.gu(90)
    maximumHeight: units.gu(120)
    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 ubuntu-phone@lists.launchpad.net mailing list, on Telegram and on all commonly used public platforms. We are happy to listen to you and answer your questions.

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
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.

API

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.

Behavior

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).

Performance

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.

Styling

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

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

When Do We Start?

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

When Will It Be Available?

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

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

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

Final words

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

 

Read more
Didier Roche

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


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

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

The deadline to participate is March 25, 2016.

Read more
Zoltán Balogh

SDK Planning for 16.10

On your mark!

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

  • AdaptivePageLayout

  • Page  

  • Picker

  • DateTimePicker

  • TextField

  • TextArea

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

Closing the feature gaps

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

  • header subtitle  

  • keyboard control for the header

  • toolbar scrolling

  • exclusive group

  • radio buttons  

  • popup window

  • context menus  

  • new dialog component  

  • context menu

  • application menu

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

APIs and Frameworks

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

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

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

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

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

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

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

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

UITK v2.0

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

Development Tools and IDE

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

Integration and releases

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

Keeping it all open

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

 

Read more
David Callé

Last weekend for the Scopes Showdown!

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

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

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

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

Happy hacking !

Read more
Tim Peeters

PageHeader tutorial

The new header property

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

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

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

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

 

Example 1

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    width: units.gu(50)
    height: units.gu(30)
    Page {
        id: page
        header: Rectangle {
            color: UbuntuColors.orange
            width: parent.width
            height: units.gu(8)
            Label {
                anchors.centerIn: parent
                text: "Title"
                color: "white"
            }
        }
        Rectangle {
            anchors {
                left: parent.left
                right: parent.right
                bottom: parent.bottom
                top: page.header.bottom
            }
            color: UbuntuColors.blue
            border.width: units.gu(1)
            Label {
                anchors.centerIn: parent
                text: "Hello, world!"
                color: "white"
            }
        }
    }
}

Use PageHeader for an Ubuntu header

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

Example 2

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    width: units.gu(50)
    height: units.gu(20)
    Page {
        header: PageHeader {
            title: "Ubuntu header"
            leadingActionBar.actions: [
                Action {
                    iconName: "contact"
                    text: "Navigation 1"
                },
                Action {
                    iconName: "calendar"
                    text: "Navigation 2"
                }
            ]
            trailingActionBar.actions: [
                Action {
                    iconName: "settings"
                    text: "First"
                },
                Action {
                    iconName: "info"
                    text: "Second"
                },
                Action {
                    iconName: "search"
                    text: "Third"
                }
            ]
        }
    }
}

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

Automatic show/hide behavior

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

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    width: units.gu(50)
    height: units.gu(40)
    Page {
        header: PageHeader {
            title: "Ubuntu header"
            flickable: listView
            trailingActionBar.actions: [
                Action {
                    iconName: "info"
                    text: "Information"
                }
            ]
        }
        ListView {
            id: listView
            anchors.fill: parent
            model: 20
            delegate: ListItem {
                Label {
                    anchors.centerIn: parent
                    text: "Item " + index
                }
            }
        }
    }
}

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

Extending the header

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

Example 4a

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

Customize the looks

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

Example 5

import QtQuick 2.4
import Ubuntu.Components 1.3
MainView {
    width: units.gu(50)
    height: units.gu(20)
    Page {
        header: PageHeader {
            title: "Ubuntu header"
            StyleHints {
                foregroundColor: "white"
                backgroundColor: UbuntuColors.blue
                dividerColor: UbuntuColors.ash
                contentHeight: units.gu(7)
            }
            trailingActionBar {
                actions: [
                    Action {
                        iconName: "info"
                        text: "Information"
                    },
                    Action {
                        iconName: "settings"
                        text: "Settings"
                    }
                ]
            }
        }
    }
}

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

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

Read more
Robin Winslow

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

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

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

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

GitHub Pages

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

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

GitHub pages minimal files

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

automatic page generator themes

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

mytestwebsite GitHub pages

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

mytestwebsite GitHub pages files

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

CloudFlare

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

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

Setting up HTTPS

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

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

mytestwebsite CloudFlare DNS setup

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

CloudFlare full SSL encryption

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

mytestwebsite with a secure domain

Ensuring all visitors use HTTPS

To make our site properly secure, we need to ensure all users are sent to the HTTPS site (https://mytestwebsite.robinwinslow.uk) instead of the HTTP one (http://mytestwebsite.robinwinslow.uk).

Setting up a page rule

The first step to get visitors to use HTTPS is to send a 301 redirect from http://mytestwebsite.robinwinslow.uk to https://mytestwebsite.robinwinslow.uk.

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

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

CloudFlare always use HTTPS page rule

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

$ curl -I mytestwebsite.robinwinslow.uk
HTTP/1.1 301 Moved Permanently
...
Location: https://mytestwebsite.robinwinslow.uk/

HTTP Strict Transport Security (HSTS)

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

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

CloudFlare: HSTS setting

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

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

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

That's it!

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

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

Read more
Robin Winslow

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

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

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

from wsgiref.simple_server import make_server

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

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

    start_response(http_status, response_headers)
    return [response_text]

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

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

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

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

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

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

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

(Also posted over on robinwinslow.uk).

Read more
Zsombor Egri

UI Toolkit for OTA9

Hello folks, it’s been a while since the last update came from our busy toolkit ants. As OTA9 came out recently, it is the time for a refreshment from our side to show you the latest and greatest cocktail of features our barmen have prepared. Beside the bugfixes we’ve provided, here is a list of the big changes we’ve introduced in OTA9. Enjoy!

PageHeader

One of the most awaited components is the PageHeader. This now makes it possible to have a detached header component which then can be used in a Page, a Rectangle, an Item, wherever you wish. It is composed of a base, plain Header component, which does not have any layout, but handles the default behavior like showing, hiding the header and dealing with the auto-hiding when an attached Flickable is moved. Some part of that API has been introduced in OTA8, but because it wasn’t yet polished enough, we decided not to announce it there and provide more distilled functionality now.

The PageHeader then adds the navigation and the trailing actions through the - hopefully - well known ActionBar component.

Toolbar

Yes, it’s back. Voldemort is back! But this time it is back as a detached component :) The API is pretty similar to PageHeader (it contains a leading and trailing ActionBar), and you can place it wherever you wish. The only restriction so far is that its layout only supports horizontal orientation.

Facelifted Scrollbar

Yes, finally we got a loan headcount to help us out in creating some nice facelift for the Scrollbar. The design follows the same principles we have for the upcoming 16.04 desktop, with the scroll handler residing inside the bar, and having two pointers to drive page up/down scrolling.

This guy also convinced us that we need a Scrollview, like in QtQuick Controls v1, so we can handle the “buddy” scrollbars, the situation when horizontal and vertical scrollbars are needed at the same time and their overlapping should be dealt with. So, we have that one too :) And let's name the barman: Andrea Bernabei aka faenil is the one!

The unified BottomEdge experience

Finally we got a complete design pattern ready for the bottom edge behavior, so it was about the time to get a component around the pattern. It can be placed within any component, and its content can be staged, meaning it can be changed while the content is dragged. The content is always loaded asynchronously for now, we will add support to force synchronous loading in the upcoming releases.

Focus handling in CheckBox, Switch, Button ActionBar

Starting now, pressing Tab and Shift+Tab on a keyboard will show a focus ring on components that support it. CheckBox, Switch, Button and ActionBar have this right now, others will follow soon.

Action mnemonics

As we are heading towards the implementation of contextual menus, we are preparing a few features as prerequisite work for the menus. For one adding mnemonic handling to Action.

So far there was only one way to define shortcuts for an Action, through the shortcut property. This now can be achieved by specifying the mnemonic in the text property of the Action using the ‘&’ character. This character will then be converted into a shortcut and, if there is a hardware keyboard attached, it will underline the mnemonic.

Read more
David Callé

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

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

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

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

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

Read more
David Planella

Ubuntu is about people

Ubuntu has been around for just over a decade. That’s a long time for a project built around a field that evolves at such a rapid pace as computing. And not just any computing –software made for (and by) human beings, who have also inevitably grown and evolved with Ubuntu.

Over the years, Ubuntu has changed and has lead change to keep thriving in such a competitive space. The first years were particularly exciting: there was so much to do, countless possibilities and plenty of opportunities to contribute.

Everyone that has been around for a while has fond memories of the Ubuntu Developer Summit, UDS in short. An in-person event run every 6 months to plan the next version of the OS. Representatives of different areas of the community came together every half year, somewhere in the US or Europe, to discuss, design and lay out the next cycle, both in terms of community and technology.

It was in this setting where Ubuntu governance and leadership were discussed, the decisions of which default apps to include were made, the switch to Unity’s new UX, and much more. It was a particularly intense event, as often discussions continued into the hallways and sometimes up to the bar late at night.

In a traditionally distributed community, where discussions and planning happen online and across timezones, getting physically together in one place helped us more effectively resolve complex issues, bring new ideas, and often agree to disagree in a respectful environment.

Ubuntu Catalan team party

This makes Ubuntu special

Change takes courage, it takes effort in thinking outside the box and going all the way through, but it is not always popular. I personally believe, though, that without disruptive changes we wouldn’t be where we are today: millions of devices shipped with Ubuntu pre-installed, leadership in the cloud space, Ubuntu phones shipped worldwide, the convergence story, Ubuntu on drones, IoT… and a strong, welcoming and thriving community.

At some point, UDS morphed into UOS, an online-only event, which despite its own merits and success, it does admittedly lack the more personal component. This is where we are now, and this is not a write-up to hark back to the good old days, or to claim that all decisions we’ve made were optimal –acknowledging those lead by Canonical.

Ubuntu has evolved, we’ve solved many of the technological issues we were facing in the early days, and in many areas Ubuntu as a platform “just works”. Where we were seeing interest in contributing to the plumbing of the OS in the past, today we see a trend where communities emerge to contribute taking advantage of a platform to build upon.

Ubuntu Convergence

The full Ubuntu computer experience, in your pocket

Yet Ubuntu is just as exciting as it was in those days. Think about carrying your computer running Ubuntu in your pocket and connecting it to your monitor at home for the full experience, think about a fresh and vibrant app developer community, think about an Open Source OS powering the next generation of connected devices and drones. The areas of opportunity to get involved are much more diverse than they have ever been.

And while we have adapted to technological and social change in the project over the years, what hasn’t changed is one of the fundamental values of Ubuntu: its people.

To me personally, when I put aside open source and exciting technical challenges, I am proud to be part of this community because its open, welcoming, it’s driven by collaboration, I keep meeting and learning from remarkable individuals, I’ve made friendships that have lasted years… and I could go on forever. We are essentially people who share a mission: that of bringing access to computer to everyone, via Free Software and open collaboration.

And while over the years we have learnt to work productively in a remote environment, the need to socialize is still there and as important as ever to reaffirm this bonding that keep us together.

Enter UbuCons.

The rise of the UbuCons

UbuCons are in-person conferences around the world, fully driven by teams of volunteers who are passionate about Ubuntu and about community. They are also a remarkable achievement, showing an exceptional commitment and organizational effort from Ubuntu advocates to make them happen.

Unlike other big Ubuntu events such as release parties -celebrating new releases every six months- UbuCons happen generally once a year. They vary in size, going from tens to hundreds to thousands, include talks by Ubuntu community members and cross-collaboration with other Open Source communities. Most importantly, they are always events to remember.

UbuCons across the globe

A network of UbuCons

A few months back, at the Ubuntu Community Team we started thinking of how we could bring the community together in a similar way we used to do with a big central event, but also in a way that was sustainable and community-driven.

The existing network of UbuCons came as the natural vehicle for this, and in this time we’ve been working closely with UbuCon organizers to take UbuCons up a notch. It has been from this team work where initiatives such as the UbuContest leading to UbuCon DE in Berlin were made possible. And more support for worldwide UbuCons general: in terms of speakers and community donations to cover some of the organizational cost for instance, or most recently the UbuCon site.

It has been particularly rewarding for us to have played even a small part on this, where the full credit goes to the international teams of UbuCon organizers. Today, six UbuCons are running worldwide, with future plans for more.

And enter the Summit

Community power

Community power

But we were not content yet. With UbuCons covering a particular geographical area, we still felt a bigger, more centralized event was needed for the community to rally around.

The idea of expanding to a bigger summit had already been brainstormed with members of the Ubuntu California LoCo in the months coming to the last UbuCon @ SCALE in LA. Building up on the initial concept, the vision for the Summit was penciled in at the Community Leadership Summit (CLS) 2015 together with representatives from the Ubuntu Community Council.

An UbuCon Summit is a super-UbuCon, if you will: with some of the most influential members of the wider Ubuntu community, with first-class talks content, and with a space for discussions to help shape the future of particular areas of Ubuntu. It’s the evolution of an UbuCon.

UbuCon Europe planning

The usual suspects planning the next UbuCon Europe

As a side note, I’m particularly happy to see that the US Summit organization has already set the wheels in motion for another summit in Europe next year. A couple of months ago I had the privilege to take part in one of the most reinvigorating online sessions I’ve been in recent times, where a highly enthusiastic and highly capable team of organizers started laying out the plans for UbuCon Europe in Germany next year! But back to the topic…

Today, the first UbuCon Summit in the US is brought to you by a passionate team of organizers in the Ubuntu California LoCo, the Ubuntu Community Team at Canonical and SCALE, who hope you enjoy it and contribute to the event as much as we are planning to :-)

Jono Bacon, who we have to thank for participating in and facilitating the initial CLS discussions, wrote an excellent blog post on why you should go to UbuCon in LA in January, which I highly recommend you read.

In a nutshell, here’s what to expect at the UbuCon Summit:
– A two-day, two-track conference
– User and developer talks by the best experts in the Ubuntu community
– An environment to propose topics, participate and influence Ubuntu
– Social events to network and get together with those who make Ubuntu
100% Free registration, although we encourage participants to also consider registering for the full 4 days of SCALE 14x, who are the host to the UbuCon

I’m really looking forward to meeting everyone there, to seeing old and new faces and getting together to keep the big Ubuntu wheels turning.

The post Ubuntu is about people appeared first on David Planella.

Read more
Benjamin Zeller

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

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

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

https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa

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

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

sudo apt-get remove qtcreator qtcreator-plugin*

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

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

That was easy, wasn’t it :).

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

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

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

Read more

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

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

Read the tutorial ›

Read more
Thibaut Rouffineau

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read more
David Planella

Ubuntu Online Summit
Starting on Tuesday 3rd to Thursday 5th of November, a new edition of the Ubuntu Online Summit is taking place next week.

Three days of free and live content all around Ubuntu and Open Source: discussions, tutorials, demos, presentations and Q+As for anyone to get in touch with the latest news and technologies, and get started contributing to Ubuntu.

The tracks

As in previous editions, the sessions runs along multiple tracks that group related topics as a theme:

  • 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

The highlights

Here are some of my personal handpicks on sessions not to miss:

  • Opening keynote: Mark Shuttleworth, Canonical and Ubuntu founder will be opening the Online Summit with his keynote, on Tuesday 3rd Nov, 14:00 UTC
  • Ask the CEO: Jane Silber, Canonical’s CEO will be talking with the audience and answering questions from the community on her Q+A session, on Wednesday 4th Nov, 17:00 UTC
  • Snappy Clinic: join the snappy team on an interactive session about bringing robotics to Ubuntu – porting ROS apps to snappy Ubuntu Core, on Tuesday 3rd Nov, 18:00 UTC
  • JavaScript scopes hands-on: creating Ubuntu phone scopes is now easier than ever with JavaScript; learn all about it with resident scopes expert Marcus Tomlinson on Thursday 5th Nov, 15:00 UTC
  • An introduction to LXD: Stéphane Graber will be demoing LXD, the container hypervisor, and discussing features and upcoming plans on Thursday 5th Nov, 16:00 UTC
  • UbuCon Europe planning: a community team around the Ubuntu German LoCo will be getting together to plan the next in-person UbuCon Summit in Europe next year on Wednesday 4th Nov, 18:00 UTC

Check out the full schedule for more! >

Participating

Joining the summit is easy. Simply remember to:

Once you’ve done that, there are different ways of taking part online event via video hangouts and IRC:

  • 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.
  • 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 The Ubuntu Online Summit starts next week appeared first on David Planella.

Read more