Rick's Ubuntu for Phones FAQ

Why is the Ubuntu Team So Excited about Ubuntu for Phones?

13.10 represents a major step forward for the Ubuntu project, because the Ubuntu phone images feature a set of new technologies that solve many of the longstanding difficulties with Ubuntu distros. Specifically:

1. Image based updates
2. A complete SDK
3. Application Isolation
4. Click packages and click installer with app store
5. Mir Display Server and Window Manager
6. Unity 8

Image based updates

Image based updates are a new of getting updates on Ubuntu. In the past, all versions of Ubuntu (and on Ubuntu Server and Desktop for 13.10 and beyond) updates were done with apt. Apt is the tool for debian package management. It was capable of calculating which packages needed to be updated or upgraded, and then ran those updates. Apt works well on servers and desktops because it supports complicated dependencies. However, it also takes a lot of computing horsepower to compute the updates or upgrades, and due to it being complicated, could occasionally get into situations that needed to be fixed with some command line options.

Ubuntu needed to take much less energy and time to perform updates, and needed to be much more reliable. This is where image-based updates come in. The Ubuntu images for phones have a read only file system by default, and a specific partitioning scheme for the drives. User data and applications are kept on a separate partition from the underlying system. As a result, if our update servers know which build you are running, they have an exact copy of the system on the servers. So rather than calculating package upgrade paths on your computer, the server can simply calculate a binary diff and the phone downloads only the diff for the system. Ubuntu then applies the diff and reboots into the update image. This has the added benefit that the downloads of the updates are much smaller, since users only have to download what has changed.

This all happens over the air. You can access this function from the Updates panel of the system settings application. Note that the phone can still be put into “system builder mode” which allows a user full access to all of the power of Apt, if they want to hack on their phones.

A Complete SDK

Ubuntu for phones provides three ways of developing applications for end users:

1. Web apps
2. Phone gap
3. Ubuntu SDK

Web apps and phone gap support is tried and true technology for delivering HTML 5 applications to end users and we are proud to offer these options to developers. But what if you want to write a native app that looks like the core Ubuntu applications? Ubuntu now offers an SDK which includes the QtCreator development environment, the Qt library, the Ubuntu UI Toolkit, and many Ubuntu services, such as the Friends API for writing socially connected apps.

Application Isolation

Ubuntu on the phone runs applications under App Armour. App Armour is a kernel feature which ensures that processes are simply not able to access any resources to which they are not entitled. In this way, application are kept from interfering with each other or the underlying system in any way. This keeps the user safe from both malicious applications that may try to snoop on other applications, use services to which they are not entitled, or other naughtiness. Developers can write applications that interact with other applications, but only through strictly defined and secure APIs.

One result of this much higher level of isolation, is that applications do not need to go through the same degree scrutiny to ensure that they are safe. As such, we can publish new applications to stable releases orders of magnitude faster than ever before. It often takes less than 30 minutes for an application to be submitted, reviewed, and appear in the application store.

Click Packages

Ubuntu for phones offers a brand new and much simpler means of packaging and installing applications. For other Ubuntu images, apps needed to be packaged as debian files (.deb files). This required the developer to have significant skill in packaging in order to manage the dependencies.

Click packages are much simpler because applications can depend only upon the “base sdk” which is installed on all phones, or on libraries bundled directly with the application. Since click packages are uploaded to the store and run under application isolation, it is very easy and fast for an application developer to get their applications to users.

Mir Display Server and Window Manager

The Ubuntu Desktop has always depended on implementations of the X11 protocol (xorg). This technology is more than 20 years old and designed for very different systems than are available today. Between the complexity of the protocol and the drivers, it is a significant effort to deliver a stable and fast system to end users. Even with this effort, their systems sometime regress or break, especially if the users are using drivers from their GPU chip vendor. Writing a window manager on top of this protocol also turned out to be very complex, often due to differences in the implementations of APIs in the GPU drivers, and also due to complexities in the X11 protocol.

The Mir display server solves these problems by offering a simpler and more direct library to both GPU driver developers and Window Manager authors. Mir is also designed to work easily with existing Android drivers.

The Mir display server on Ubuntu for phones is carefully designed by the Ubuntu design team, and takes advantage of the simpler more direct Mir API to deliver faster development and a better user experience.

Mir display server and window manager are currently optimized for phones and to some degree tablets, but will grow over the next few releases to provide a full desktop experience as well.

Unity 8

Finally, Ubuntu phone images feature the latest version of the Ubuntu shell, called “Unity 8”. It features enhancements to the launcher and to indicators that make them very user friendly even when operated with just a thumb while holding a phone, as well as the latest iteration of the dash that includes scopes optimized for mobility, providing touch optimized access to music, video, and applications.

What is “Ubuntu Touch”?

“Ubuntu Touch” is the development codename for the special images of Ubuntu that were created to run on phones and tablets. There are some technical differences in terms of how the phones are updated, which apps can run and how they are installed, and the display server. However, these differences are small compared to the similarities. Officially, these images are simply named “Ubuntu”.

How Do I Get and Use Ubuntu on a Phone?

Ubuntu 13.10 will have images that work for the Galaxy Nexus and the Nexus 4. They are available in the normal places. However, phones require special steps for installing a new OS. Aside from the officially supported images, the community has created a set of ports for their own devices, you can find that list here: https://wiki.ubuntu.com/Touch/Devices

Will Ubuntu Work on My Tablet?

We are making Ubuntu images for the first version of the Nexus 7 and the Nexus 10. These images are available alongside images for phones, and the installation experience is similar. However, please note that we in Ubuntu prioritized making Ubuntu working for phones for 13.10, so the tablet images are still in “early preivew stages” There are bugs and missing functionality. We plan to focus on tablets more fully for 14.04.

Is Ubuntu Finished for Phones?

Yes and no. We are proud that Ubuntu 13.10 is a complete 1.0 solution for powering your phone. Many of us have been using Ubuntu as our on our only phone for months. However, it does have one or two features that you may miss and that will be added very soon. For example, Ubuntu 13.10 does not have a lock screen when running on a phone. There are some settings, such as a convenient airplane mode that have not been implemented yet, but will be shortly.

Of course, we also have a list of enhancements and new features for the 14.04 as well!

If I Install Ubuntu on my Phone, How Will it be Supported?

The images for phones feature a new way to update that we call “image based updates”. For about a month after we release 13.10, expect to get updates for only the most critical bugs. However, after about a month, all users will be upgraded to the current development version. This will allow users to get the latest features and bug fixes without having to wait six months.

Can I Run my Favorite Application on My Phone?

This depends on the application. If your favorite app is a web app, then you are in luck. Ubuntu ships many web applications in a manner that is well integrated into the overall phone experience. Also, there is a good chance that your favorite application has a version made especially to run on phones running Ubuntu. However, applications that require a keyboard and mouse, or that require a toolkit that is not supported on Ubuntu will not run on the phone until it is ported.

Can I Run a Desktop from My Phone Like I’ve Seen in Demos?

This represents our ultimate goal for what what we call “convergence”, one device with all the functionality you need from various devices converged together. In 13.10 we have made great strides towards convergence. Most of the software running on Ubuntu for desktop images and Ubuntu for phone images is the same. However, Ubuntu does not yet have the capability for a phone to dock into a desktop, yet. We continue to work very hard toward this goal, and all of our development is geared towards reaching it.

The Big Rocks of August

Have you ever heard the phrase "If you don't put the big rocks in first, you'll never get them in at all"? It's from an oft repeated parable about life and also project management.

Last week I met with Canonical's Ubuntu Engineering leadership team (me, the Directors, Engineering Managers, Tech Leads, and Architects). We took a close look at the progress of Ubuntu Touch from many points of view. All in all, I left last week feeling quite satisfied that Ubuntu Touch for phones was on track for a very good 1.0 release in October. However, we identified that there were some "big rocks" that we didn't get in the jar yet, and that we needed to get them in asap if we were going to finish with the kind of systematic development process that will be necessary to make 13.10 rock.

So, we set the goal for August to get all the big rocks in. The 5 big rocks ...

Image Based Upgrades

Blueprint is here

The first big rock is Image Based Upgrades. Today, when we "bless" a new image, one must use a tool on your desktop called "phablet-flash" to update to that new image. After August, the phone will download updates over wireless and install them without requiring a connection to the desktop. As you can see in the blueprint, this requires some deep changes to the way Ubuntu works (as well as to our automated testing) in order to do it as robustly as is necessary for this market (a.k.a. no "dpkg --configure -a"). The disks must be partitioned so that the system is total separate from user data. The server must calculate the binary diff of an update for that partition, and the diff must be applied safely and reliably.

All of this work is in place now on the client and server and being tested. Wet need to bring it together and start using it. We will do so in August.

Indicators

Ubuntu touch is designed to support user settings in 2 ways. The most common and dynamic settings are available from the indicators, others from the settings application.

The settings application has a long tail of settings, some more important than others. The indicators, have limited, but critical functionality. By the end of August, all of the indicators will be functional. As a result, most of the back-end work will be in place to finish settings in September and October as well.

Click

Martin Albeseti is working on a new video, but there is as starter one here if you want to see an end to end demo.

How developers write applications, how users install applications, and how those applications run ... what a huge topic. By the end of August, Ubuntu Touch will be doing this in a different and new way.

Of course, we all know that developers will use the sweet Ubuntu SDK to get write their sweet apps ;) However, did you know that developers will not need to package those apps into deb files? Rather they will make a simple click package that includes their code and all of their dependencies (in the case that they have dependencies that are not part of the SDK). Click packages are easy to create with Click, and support for this is even built into Qt Creator. So writing and packaging an app is now, finally, fun and easy for Ubuntu Touch.

But how will users find applications to install in Ubuntu Touch? Developers will be able to upload their applications and after a very quick review to ascertain that the requested permissions (more on that below) are reasonable, users will be able to find their apps in the apps lens! What could be easier. With a simple button click in the dash, the application will be downloaded and installed by Click.

The reason we can do such a light review is due to the something called "application confinement" which has already landed and is running on Ubuntu Touch today. Application confinement causes an application to run under apparmour, which means that the kernel controls what it has access to. As such, it is very very difficult for an application to do anything naughty.

Now, an application that is totally confined may be useful, but it may be desirable for an app to interact with data from other apps. For example, what if you wanted to import a picture from the phone? To support that, there will be a series of trusted helpers and services which can securely provide an application the data that it needs with a few simple SDK calls.

After August, when Click is working end to end on the phone, we can spend September and October adding the rest of the important features, like updating applications.

Application Lifecycle

Speaking of SDK calls, how do applications behave on the phone? On the desktop, an application can just run and run, because they have big batteries and are normally plugged in. So, a traditional Linux desktop does nothing to manage an application's use of resources.

This can't work on a phone. The reason this can't work is that phones have small batteries and are rarely plugged in. So a typical phone OS does not allow applications to just do what they want.

For Ubuntu Touch, when an application is put into the background today, it is stopped. Not killed, just stopped. The app can't use any resources and is essentially "frozen in time" until it comes to the front again. This ensures that a crazy application is only consuming resources when it is in the front, where the user is using.

But we have some work to do in August to finish the application lifestyle. First, what happens when you have so many applications open that there is no more memory? The OS has to do something to make room. In Ubuntu Touch, the OS will kill any stopped applications that haven't been used in a while in the case of low memory. But wait! you say. Won't that mean my apps get killed and I have to relaunch them and lose all my work and everything?

The answer to this problem is simple, when an application goes into the background, it will get a signal and a little time. The application can use the time to save whatever info it needs to rebuild itself in the case it gets killed while it is in the background. When the app gets called to the foreground, it can then use a little time to read whatever info it saved and rebuild itself. The result for the user will be that the app appears to just keep on running. Nice!

But Wait! What about apps that should work in the background? For example, the Music Player should keep playing while it is in the background, right? The answer to this is "sort of". An app shouldn't do anything that it would want to do in the background, but it should rather use services that work outside the scope of any one app. So the Music Player shouldn't make function calls to play music, but should rather call a system service and tell the system service what music to play.

There are several services like this that we will need in place by end of August, these include:

1. Music
2. Download
3. Telephony
4. Alarms (time)
5. Friends
6. Content
7. URI Handler
8. NITZ
9. Contacts

These services are "complete" when one can use them from the Ubuntu SDK.

Unity 8/Mir

Finally, Unity 8 (for phone only right now) is in the archive. Mir is almost in the archive. It's time to get these into the phone images so that we can spend September and October doing some nice refinements!

Conclusion

Of course not everyone in the Ubuntu community is working solely on these big rocks. So lots of other exciting stuff will happen as well. However, It's important that we get these 5 big rocks done in August. That will leave us September and part of October for us to work on the remaining list of features and requirements in priority order. After August, Ubuntu Touch will have made a dramatic step forward, really becoming the architecture that it is meant to be. I can't wait!

Passing and Being Passed

Buckley. A dog I get to pet, but do not have to walk!

Co-Working Change My Life
I got some feedback from my wife and kids last week that I seem generally happier and more "tuned in" when I am at home than I have in the past few years. Additionally  I have been feeling much more productive at work. I chalk these changes up almost totally to adopting a co-working lifestyle.

I'm sure you are all away that Canonical is mostly a distributed company. We work from all over the world in online spaces. This is great. It has meant that I have gotten to know people from all the world. I've learned a little French. I make my own schedule. Working for a distributed company has been so enriching in so many ways, I don't see how I could ever go back to a real office environment.

Working for a distributed company has also meant that I have been working at home the last 4+ years. In many ways, this has been great. I've spent zero hours commuting, as one small example. 
Office Nomads

The friendly and helpful proprietors of Office Nomads

For various reasons, I decided to give co-working a try, and I am surprised how well I have taken to it. Co-working means that I "go to work" in a large shared office space. Practically, it means that I share resources such as networking, printers, desks, dogs, etc... 

Some nomads doing their thing

The area where I work. I usually take the standing desk to the left.

On the impractical side, it means that I share in the positivity of other people also doing what they love. Hearing people work, chatting with folks when I get in, having lunch with other people, etc... This has all been great for me, personally. I think there is a certain element of just getting out of the house and not being isolated. But the atmosphere at Office Nomads is high productivity, and I can't help but to feed off the buzz. I think the community building aspects of their mission is harmonious with my values, as well.

If you work in a distributed environment, I highly recommend giving co-working a try. If you are working independently in Seattle, I strongly recommend you join Office Nomads. 

Getting There

It's been a very unreal sprint in Seattle. Reliably nice weather most days. So, since I am traveling to Office Nomads, I take my bicycle almost every day. This builds  in free exercise for me, and is slightly faster than the bus. As a result, I have been biking more and more.

I flatter myself to think that I am relatively fit these days. None the less, I get passed by other bicyclists most days. When I get passed, I notice. I noticed that I have about three responses when this happens.

• Nice Bike! Often I am passed by much more serious bicyclists, and I notice their bikes costs many times what mine costs. However, this thought is really a small cop out. The fact is, they are all probably more fit and better at bicycling than I am, and generally invest more effort it in, that's why they are passing me. If we switched bikes, they'd still be faster than me.
• Good for you! This is more typical. I can admire that the passer is more engaged, fitter, and just generally cares more about going fast at this point in time than I do. Someone going faster than me takes absolutely nothing away from my experience, and it's cool that they an do it.
• Oops. Sometimes when I get passed I realize that my mind has wandered. I forgot to keep going fast. This is helpful. Realizing that I am daydreaming instead of focused on going fast, I can decide, to go fast, or maybe I decide I am happy day dreaming. In this way, someone passing me not only doesn't take anything from me, but it grants me something positive.

I pass more people than pass me, by a wide margin. Sometimes on longer, lonelier, rides, I observer other bicyclists as I pass them. The overwhelming majority of people I pass show essentially no response. They couldn't care less that I am passing them. Some folks even take advantage of the situation and draft behind me. They can go a little faster "for free" by letting my cut through the air for them.

However, sometimes, I sense a certain amount of rage from people I pass. I can see it in their faces and body language. The fact that I am fitter and working harder takes nothing from these people, but it seems to bother them that someone can go faster than them. For this set of people, a common response is for them to work really hard to pass my back. This means that my presence was helpful for them if they want to go faster, but often, it's not sustainable for them, and I end up soon passing them again, and leaving them far behind. These folks end up with a self-inflicted net loss. They have a loss of pleasure, and they end up being driven by being passed, rather than being driven by what they want to do. A shame, really.

As an aside, one time I was coming back from a very long ride, and took a break, going slowly for a few miles before my final push home. During this time, I heard someone pumping behind me. Finally, I was passed by someone clearly working to get back in shape. I was going the perfect speed for them, just fast enough that it was a challenge to pass me. As he passed, and I saw the look of pride mixed with exhaustion on his face, my heart went out to him. When it was time for me to go fast again, I quickly caught up with him, but then I fell behind. I just didn't have the heart to show him what going really fast looks like.

The Social Phone

Yesterday I blogged about how psyched I was to have cellular data on my phone. Then I listed some things that the Ubuntu Touch needed to reach parity with my old Android phone, for me, personally. One of those missing things was a way to share images from my phone. But look! This actually works already. It turns out that there is a good start of social integration already started and working. 

Thanks to Bill Filler for walking me through the simple steps. Here's what to do if you want to get Twitter working.

Step 1: In your terminal, run the command $uoa-create twittter . So for me, I did "uoa-create twitter rickspencer3".(to get Facebook integration use $uoa-create facebook . 

Step 2: Wait for the Twitter auth web page to open. For some reason it is really tiny and you can't zoom it. The Facebook page is also tiny, but you can zoom it. However, be careful, the Facebook page requires you to click the commit button, which is way down on the bottom right. 

Step 3: Go to the Application lens. Search for the Friends app, and launch it.

Step 4: Glory in having your timeline on your phone!

Note that only Twitter and Facebook are integrated so far, more networks coming soon. Also note that you can't tweet pics from your gallery yet, but that is coming soon as well.

Of course, we can't rely on using a terminal to set up things like this. I'll be excited to see more social networks and a a GUI configurator land in the image.

Dog Fooding Success

Last week I was in Washington DC house hunting (successfully, I might add ;) ). Since I abandoned my Android phone for full time Ubuntu Touch phone, the lack of cellular data was painful, but not as painful as I thought it would be because there was wireless everywhere. However, there were a couple of times that I would have liked to have checked email and such when I wasn't around wireless. Also, I get lost easily, so not being able to check a map was a painful regression once or twice.

So, today, I was really happy to get the cellular data set up on my phone, and knock around Seattle a bit trying it out. It worked really well. It was interesting to see how so much of the slowness of my old phone was the phone itself, and not the cellular network speed as I had thought. I got a nice snappy experience on Ubuntu Touch.

In the image above, you can see that one needs to use the terminal to turn the cellular data connection on and off. I wish we had co-developed the GUI with the backend support. I would like us to start thinking more across the team, seeing if we can bring experiences out in full. That said, I know it was a huge amount of work to get data working, and having the back end working and keeping it working is certainly a solid way to develop. So, great job to the Phonedations team!

Having cellular data completes the "daily driver" goals we set! Never one to rest, now I am thinking about what would bring parity for my Ubuntu Touch phone in terms of the features that I actually used on my Android phone. The list is modest:

1. My phone sometimes gets hot and then the batter runs down faster than it should. Would love to figure out what is going on there and get longer batter life.
2. Getting pictures *off* my phone. I can take pictures, but can't share them yet.
3. Loading up and watching videos. I like to take videos to the gym and on trips and watch them on my phone sometimes.
4. Euchre. I know this is silly, but I have passed a lot of time playing this card game on my last phone. Maybe I can make my own implementation, but programming a card game seems like it would best be done with a framework, and it's not really up my ally.

I'm sure everyone has a different list like this, but I bet I am the only one with Euchre on their list. :)

all dogfood diet

Yesterday I walked to my local t-mobile store and had them cut my SIM down to "micro" size. I did this so I could fit it into my Nexus 4. I wanted to put it into my Nexus because I decided that it was ready for me to start using full time. I put my Galaxy II away. 

I decided to do this because as of yesterday I could:

• Import my contacts
• Make and receive SMSs
• Make and receive phone calls
• Use the internet via a wireless connection

It still lacks data over the cellular network. We won't get that until next week. So, I can't really say that it's dogfoodable for everyone as per our original goals, but we are close!

Dogfood Update

At the end of April, we set the goal to have Ubuntu Touch be dogfoodable on the Nexus and Nexus 4 phones. By that we mean, the goal is to make it so that we can use our phones exclusively as our phones. Today I chatted with some of the engineering managers involved to see how much progress we have made towards that. I am happy to say that it looks like we are still on track for this goal. However, there do appear to be some risky parts, so I am keeping my fingers crossed.

• You can make and receive phone calls: Done!
• You can make and receive sms messages: Done!
• You can browse the web on 3g data: Tony had been blocked on some technical issues, but thinks he's through them, so is in the debugging phase. He expects to have this done by end of May as per the dogfooding goal. For me, personally, this is the only missing part for me to be able to use the phone as my main phone around town. So, if Tony cracks this nut, then I will put away my old phone and start using my Ubuntu Phone exclusively.
• You can browse the web on wifi: Done! This has actually been done for quite a while.
• You can switch between wifi and 3g data: There are 2 parts to this work. There is low level networking code to get done, and then there is UI to enable it. That means that the Phone Foundations team and the Desktop team both have work to do. Both teams expect to get it done for May, but the work is not started yet.
• The proximity sensore dims the screen when you lift the phone to talk on it: There are two parts to this also. Gather the sensor data and then making the phone app use the sensor data. Work has not started for this part either.
• You can import contacts from somewhere, and you can add and edit contacts: There is some work done on this that imports from a *.csv file. I expect there will be some crude support for this in time for the May goal. It might be fun for someone to try out a more elegant implementation. Ubuntu Phone is using Evolution Data Server for the contacts store, so there may be folks out there who already have the experience to do this easily.
• When you update your phone your user data is retained, even if updating with phablet-flash: Done! This part being done makes the contacts import less important to me because as I add contacts they won't get blown away. On the other hand, it means it is worth it to import contacts, since you won't have to re-important as you update your phone each day (while it is in development).

Feel Like Friday (post-vUDS)

It feels like Friday! Why? I think it's because I am tired. I am tired because Virtual UDS turns out to be surprisingly intense.

Power to People

So, that is to say, the second Virtual UDS is over. After experience my second vUDS, I think vUDS is really a boost for the transparency of the Ubuntu Project for a few reasons.

• Frequency. We can do it every 3 months instead of every 6 months. As I mentioned in the opening plenary, this is important because we don't actually plan only every 6 months anymore. Like any modern software project, we are continuously planning. The 3 month cadence for vUDS means that there will be less time between detecting a need to change plans and discussion about how to make those necessary changes. I pushed very hard to have the first vUDS quickly, because there was a lot of planning for Ubuntu Touch that was backed up and needed proper discussion. If we waited until now, a lot of the work would have started without a good opportunity for discussion.
• Access. Folks don't have to travel to wherever UDS is. People with specific interests can rock those interests with a laser focus, without having to dedicate a whole week away from home. Let's face it, traveling for 2 weeks a year to participate in UDS is something that only a few privileged people can swing. Many many more people can join a hangout.
• Persistence. The sessions are streamed live, but then instantly available for reviewing, along with the white board, links to blueprints, etc... Try it. Go to Summit for the UDS that just ended. Find a session. Click on the session. It's like you are there live. Discussions that used to exist only in the memories of a select few with some written traces are now persisted and available.

Personal Faves

I won't go into a run down of the results, because that job is taken. However, here are some of my personal favorite discussions at this vUDS. These are my favorites based only on personal interests of mine. These are by no means the most important decisions or discussions. Just things that interest me a lot personally.

Rolling Release

After the unfortunate kerfufle last cycle when I pushed hard to move Ubuntu to a model of LTSs with rolling releases in between, it was niceto close in on one nice outcome. Namely, Colin has a technical solution that will allow users to subscribe to essentially the tip of development. Instead of using "raring" or "saucy" in your sources lists, you'll subscribe to a new name which is symlinked to whatever is the current development release. In this way, each day you will be on the latest. Even the day after a development release becomes a stable release, because the symlink will just point to the next development release.

I ended up with a couple of action items from this session. Mostly, to come up with a name and bring it to the next Tech Board meeting for approval. I'm very much leaning to "rolling", but I am open to discussion ;) This would mean you could say "I am on Raring", or "I am on Precise", or "I am on Rolling". "I am on Rolling" means that you are on the tip of development. Fun!

Touch Image Testing

I've been very keen to get Ubuntu Touch out of "preview" mode and into our standard development processes so that they inherit all of the daily quality tools that we have in place. This means moving all the code of out PPAs and into the real archives, so that we get the benefits of all the efforts we have put into place around -proposed and archive maintenance. It also means getting smoke testing and regression testing automated on the Touch images. I loved hearing from the Phone Foundations team and the QA team about their vision for "not accepting regressions". We should have dog-foodable touch images as early as the end of this month. Then if we can keep the images fully usable with minimal regressions each day, we will go very fast towards completion.

Ubuntu Status Stracker

I am partial to this topic because the status tracker started out as a labor of love for me. The first real bit of code that I wrote after joining canonical was to render my version of burndown charts. If I am not mistaken this code is still in use. In any case, status.ubuntu.com is critical to maintaining our planning, and ensuring that the status of the project is visible to all.

Unity 8 in 13.10

While 13.10 is very very focused on Ubunty Touch for phones, we all know that the real prize is the fully converged client OS. With that in mind, I think it's important to get the code up on as many device types as possible as soon as possible. There was a rich discussion about the steps to offer Unity 8 on top of Mir as an option in 13.10. Now, keep in mind that the result will only be the Phone UI on the desktop, and the default will be the Unity that we know and love today (with Smart Scopes and other enhancements of course!). Still in all, I am betting that basing Unity 8 on QML means that it will be surprisingly functional on a desktop even though it won't have any real desktop support in terms of things like workspace switching, etc..

A little bit of reusable code Sound Button

Want a button for Ubuntu Components that plays a sound when pressed, and stops when released? Here's SoundButton . Perfect for your typical Sound Board type app.

import QtQuick 2.0

import Ubuntu.Components 0.1

import QtMultimedia 5.0

    Button

    {

        id: soundButton

        property string soundUrl: ""

        onPressedChanged:

        {

            if(pressed)

            {

                audio.play()

            }

            else

            {

                audio.stop()

            }

        }

    Audio

    {

        id: audio

        source:soundButton.soundUrl;

    }

}

Woof woof!

Last week I fell into a discussion with Mark, Pat, and others about the importance of being able to really use a piece of software to really know how far there is between where you are, and a shippable state. Of everything that is missing, it's hard to know what is really the most important unless you can really use it and find what you have to work around, versus what you can just do without.

Out of this conversation was born the idea that we should drive as hard as we can to making it so that we can use our phones with Ubuntu Touch as our real daily phones as soon as possible. Really eat our own dogfood, so to speak. woof!

So, we committed our teams to making it so that by end of May, the phone images will be usable as our daily phones, defined as the following:

• You can make and receive phone calls
• You can make and receive sms messages
• You can browse the web on 3g data
• You can browse the web on wifi
• You can switch between wifi and 3g data
• The proximity sensore dims the screen when you lift the phone to talk on it
• You can import contacts from somewhere, and you can add and edit contacts
• When you update your phone your user data is retained, even if updating with phablet-flash

We believe that at least some of us will be able to really dogfood if we accomplish that. Of course, there will be a lot missing. Off the bat, I can thinking of things like the ability to find and install new apps, hardware not working on certain reference hardware (camera on Nexus 7 for example?), lots of missing features in existing apps, etc... However, in my experience, progress accelerates when people are using, in addition to building, software.

Ugly Duckling to Beautiful Swan, or How an App Developer Benefits from Designer/Developer Collaboration

Last week I snatched an hour here and there to work on my Feedzilla app. I like Feedzilla because it has an api that is free for me to use, so it's easy to write the app. However, I'm not totally enamored with the content, it seems like it is often out of date, though I suppose I can apply a filter to limit the content to new stuff from this week, or whatever.

However, what really stopped me working on it was that my implementation was just depressingly ugly. I'd look at all the cool and beautiful things that other people were doing with their apps, and be totally unmotivated to work on TechNews. Last week, I decided to ask for some help in how to improve my app, and I was told about ListItems. For TechNews, it was like the sun coming out from behind the clouds.

Now, the thing abut Ubuntu.Components is that the project is fundamentally a design project. Yes, the components need, and have, an awesome development team that makes them "real", but the components are really about providing developers with the tools for making a well designed "Ubuntu App". This couldn't be more clear than when using ListItems.

For an example, to turn the categories list from this:

My very ugly list which was my honest best effort without design help.

to this:

My now lovely list that I got to be that way just by using the right components and inheriting all of the designers' knowledge and talents.

I just had to use Standard list items. First, I went ahead and imported the ListItem namespace:

import Ubuntu.Components.ListItems 0.1

Then this is what my delegate for each list item looks like. The "progression: true" declares that the item will navigate somewhere. The designers ensured that this means the list item adds that ">", so it is standard navigation in all apps!

    delegate: Standard

    {

        progression: true;

        text: articlesListView.model[index]["title"]

        onClicked:

        {

            articleSelected(articlesListView.model[index]["url"])

        }

     }

So my app went from ugly duckling to beautiful swan just by using the right components and getting all the benefit of the designers' abilities that I so sorely lack. Thanks SDK team!

FingerPaint, my 20 minute app

Here's a quick demo of using InkCanvas.

First I create a rectangle to fill the window to make everything white. Then I made an InkCanvas and set the InkWidth to something like a kid would finger paint:

        InkCanvas

        {

            id: inkCanvas

            width:parent.width

            height:parent.height - paintPotSize

            inkWidth: 30

        }

So, now that I have an InkCanvas component, the inking is the easy part. I spent most of the 20 minutes working on the paint color selector.

Those blocks along the bottom are MouseAreas filled with UbuntuShapes. So I just respond to the clicked signal and set the InkCanvas's inkColor property ...

Using a Repeater, I can set them up like this:

        Row

        {

            width: parent.width

            height: paintPotSize

            Repeater

            {

                model: [Qt.rgba(1,0,0,.5), Qt.rgba(0,1,0,.5), Qt.rgba(0,0,1,.5),

                        Qt.rgba(1,1,0,.5), Qt.rgba(1,0,1,.5), Qt.rgba(0,1,1,.5)]

                MouseArea

                 {

                    height: paintPotSize

                    width: paintPotSize

                    onClicked: {inkCanvas.inkColor = modelData}

                    UbuntuShape

                    {

                        anchors.fill: parent

                        color: modelData

                    }

                }

            }

        }

Tada ... a finger paint program suitable for kids to get their grubby mits all over your device in 20 minutes :)

Code is here

Introducing InkCanvas

So, I drew a beard on Tard today!  Furthermore, I did it with just a few lines of QML. Here's the whole program for drawing on Tard ...

MainView {

    // objectName for functional testing purposes (autopilot-qt5)

    objectName: "mainView"

    applicationName: "InkArea"

    width: units.gu(100)

    height: units.gu(75)

    Image

    {

        source: "grumpycat.jpg"

        anchors.fill: parent;

        fillMode: Image.PreserveAspectFit

    }

    InkCanvas

    {

        anchors.fill: parent

        inkColor: Qt.rgba(0, 0, 0)

        inkWidth: 15

    }

}

I just added an InkCanvas to my MainView and covered the Image with it. Simple, right? Well, you may have guessed there is slightly more to it than that. Where did InkCanvas come from? InkCanvas is a custom component that I wrote in pure QML to allow users to draw an a surface.

You may be aware of my long interest in free from editing applications. Remember Photobomb?

So, I decided to try my hand at collecting Ink in QML. There was some surprising complexity in getting it to work and work quickly, and it is still very much a work in progress. None the less, I want to invite people to:

• Download and use InkCanvas in their apps if they want. I hope it unlocks some fun things for people to do.
• Contribute to making InkCanvas better. Extend it, fix it, break it, etc...

Note that it currently doesn't work perfectly on my Nexus7. Something seems to break the canvas when Ink starts getting drawn :(

I logged a bug about this, but for all I know, it has something to do with the way I am abusing the Canvas and Stroke Components. Though it does work fine on my desktop.

Easy Task Navigation With PageStack (Fixed)

Thanks to an update to the documentation for Ubuntu Components, I discovered that I was using PageStack all wrong. I've gone ahead and deleted my old blog post about PageStack, and now here is a corrected one.

My Feedzilla app has a very simply page by page structure. Each bit of UI that the user interacts with is a wholly separate task so can take over the whole screen to present to the user.

Turns out, that Ubuntu Components have a component to support this in a standard, and very convenient, manner. It's called PageStack.

Here's how it works.

First, I created a PageStack component, and named it "rootStack". The categories view is always the starting point of the app, so I made it a Page inside the PageStack, and named it "rootPage". Then I added SubCategoriesPage (which is a ListView that shows the list of Technology sub-categories from Feedzilla:

It looks like this.
    PageStack
    {
        id: rootStack
        Page
        {
            title: "Categories"
            id: rootPage
            SubCategoriesComponent
            {
                id: subCategoriesComponent
                anchors.fill: parent
            }
        }
    }

Now, even though rootPage is visible, it's not actually on the PageStack yet. PageStack is a "stack" in the programming sense. That means you can push items on top of the stack, and pop items off. So I need to write some code to push rootPage onto the PageStack. I do this by adding an onCompleted handler to the PageStack and pushing the rootPage onto the PageStack there.

    PageStack
    {
        id: rootStack
        Page
        {
            title: "Categories"
            id: rootPage
            SubCategoriesComponent
            {
                id: subCategoriesComponent
                anchors.fill: parent
            }
        }
      Component.onCompleted:
      {
            push(rootPage)
      }
   }

So, how does the user navigate? I added a signal to SubCategoriesComponent for when the user has selected a category.

I made two other Components. One for displaying a list of articles and one for displaying articles themselves. I host these components inside of pages. I also set the pages to be invisible.


    Page
    {
       visible: false
       id: articlesListPage;
       ArticlesListComponent
        {
            id: articlesList
            anchors.fill: parent;
            onArticleSelected:
            {
                articleComponent.url = url
                rootStack.push(articlePage)
            }
            onTitleChanged:
            {
                articlesListPage.title = articlesList.title
            }
        }
      }
      Page
      {
        visible: false
        id: articlePage
        ArticleComponent {
            id: articleComponent
            anchors.fill: parent;
        }
      }

When the user selects a category, they need to see a list of articles. I made ArticlesListComponent todo that job. When they select a specific article, the user should see the article, I created ArticleComponent for that. Note:

So, getting back to the story, how do we push these onto the PageStack?

        Page
        {
            title: "Categories"
            id: rootPage
            SubCategoriesComponent
            {
                id: subCategoriesComponent
                anchors.fill: parent
                onSubCategorySelected:
                {
                    articlesList.subCategoryId = subCategoryId;
                    rootStack.push(articlesListPage)
                }
            }
        }

You may recall that I added a onSubCategorySelected signal to my SubCategoriesComponent component. All I have to do is respond to that signal. First I configure my ArticlesListPage to use the sunCategoryId passed into the signal handler. Then I tell the PageStack to push articlesListPage (the instance of ArticlesListPage declared in the QML above). Pushing 'pushes' pushes the component on top of the categories list.

I use similar code to push the ArticlesComponent when the user selects an article.
            onArticleSelected:
            {
                articleComponent.url = url
                rootStack.push(articlePage)
            }

The ArticleComponent can only be on top, so it doesn't push anything.

But what about going back? That's where popping comes in. I added an action to rootPage which simply tells rootStack to pop. Pop is opposite of push. Instead of adding something to the top of the stack, it takes whatever is on top off. It pops off the top. rootPage can't be popped off, though, because it is at the root. This makes the code easy. If I wanted to, I could handle popping myself with code like this:
            tools: ToolbarActions
            {
                Action
                {
                    id: backAction
                    text: "Back"
                    iconSource: "back.png"
                    onTriggered:
                    {
                        rootStack.pop();
                    }
                }
            }
     

However, this is not necessary because PageStack automatically creates and maintains a back button for me!

I pushed a branch with my corrected code.