snap up your home

Recently I had some fun with playing with Ubuntu on the Orange Matchbox, a Raspberry PI2 in a pretty Ubuntu case, preloaded with Snappy Ubuntu Core.

… and what would be better suited for that as having a try with guh on it. If you haven’t heard about guh (gear up you home) yet, it’s basically an open source plugin-based home automation server with a sophisticated if-this-than-that framework. For more details check out the guh wiki and the guh tune website.

So far guh has been targeting Ubuntu and I felt like it’s about time to give it a try on Ubuntu Snappy. With the Orange Matchbox running the latest Ubuntu Snappy release, it was much easier than expected to get all the things up and running on it. The short story is that I used the Ubuntu SDK and a 15.04 click chroot to cross compile things. After all click and snappy seemed similar enough to me. When it failed building the click package I went to the build directory and called “snappy build” on it instead of the “click build” command that the Ubuntu SDK usually runs. Here’s the diff that was required to completely cross-build and deploy guh-core to a folder that can be packaged up: github link. On top of guh-core there’s a webserver providing a RESTful API. As it’s written in go it was similarly easy to get a cross-built armhf binary and copy that to the package directory. Python seems to be preinstalled on the snappy core, so the guh-cli tool could also just be copied into that folder and everything was in place. While much of this is quite hacky and surely not the final solution, it also shows how easy it can be to create snaps of somethings.

We’ll try to get the guh package into the snappy store. Before that we still need to figure how to deal with permissions. Given that guh can interact with different hardware but snappy apps/services are confined we might hit some obstacles. Also we want to get a multiarch package ready which seems to be really easy at this point as compiling for x86 is easier than cross-compiling and the snappy magic is mostly in place already. For now you can try the unconfined armhf based snap package for guh here. Even though this are first steps with snappy, it should be quite functional already.

After installing, the guh.guhd service should autostart and you can immediately use guh.guh-cli to configure your system. You can also have a glance at the webinterface, which will be running on port 3000, but keep in mind that it is quite limited for now. An app for Android is on the way too and will be published soon. It is written with cordova and I have already given it a try to port it to the Ubuntu phone, but I failed so far. If you have some experience with cordova, it would be great if you could try your luck on this repository.

After I’ve been bootstrapping guh on snappy, by now, Simon, the upstream guh developer has taken the lead already and went ahead to clean up things, preparing a snappy tools repository for guh. In there you should find the latest and greatest to build guh for snappy yourself.

Please join us in IRC channel #guh on freenode to give feedback and if you have questions or would like to help out with snappifying it and or porting the cordova control app to Ubuntu. If you think guh would be perfectly suited for your home, but doesn’t yet support some hardware you need, check out the plugin developer and other guh api docs.

Posted in Ubuntu, Uncategorized | Leave a comment

More levels for Machines vs. Machines

You wish! But no, this isn’t me announcing more levels. Instead, let me tell you how you can create some. But first, if you don’t know what Machines vs. Machines is, check out here.

Machines vs. Machines

If you have some graphics skills and know your way around with copying files/folders between your PC and the phone, it’s really straight forward to create a new level pack. No need to touch a single line of code. And this is how it’s done:

First check out a copy of lp:machines-vs-machines/levelpacks. In there you’ll find the existing level pack. Create a new sub-directory for your level pack, for example “my-first-level-pack”. All the files for your level pack should be inside this directory. The first step is to create a levelpack.json file. This file holds some basic description about your level pack. It holds the pretty formatted name, a file name for the title image, a copyright notice and the file name for the title sound:

"name": "My first level pack",
"copyright": "My full name",
"titleImage": "some-image-file",
"titleSound": "some-sound-file"

Place the image file in the same directory as this json file. The sound files instead are collected in the sounds folder.

title image for your level pack

In order to create levels you need to define some towers and enemies first. Let’s start with some enemies. Create a sub-directory called “enemies” containing a text file named “enemies.json”. Here is an example for its content:

"id": 1,
"speed": 0,
"energy": 10,
"reward": 5,
"image": "enemy-1",
"spriteCount": 1
"id": 2,
"speed": 1,
"energy": 15,
"reward": 10,
"image": "enemy-2",
"spriteCount": 8

This example file describes two enemies with different properties. The first enemy is a static image, it moves at the lowest speed and doesn’t stand many hits. It gives 5$ reward when defeated. The second one however, is an animated one, it moves a bit faster, is stronger and is rewarded with 10$. “image” holds the file name of the image file containing the enemy artwork.

Lets look at the contents of the image file: All images need to be in SVG format and should be readable by Inkscape as this will be used to generate png files in the end. All image sizes are defined by a base size of 256×256 pixels. If your image is a static image, it needs to have a page size of 256×256. For an animation with, lets say 5 frames, you need to set the page size to 5 times 256×256 squares, aligned in one row. This means the total page size needs to be 1280×256 pixels.

Set the “spriteCount” property to the amount of frames in your animation. To define the speed of the animation, additionally set the “animationDuration” property.

An enemy with different perspectives

Optionally, for enemies you can add different perspectives. If you want your enemy to look different whether it’s walking left or right, up or down, add up to 4 rows, containing single images or an animation sequence. The rows will be taken in this order: left, right, front, back.

An enemy with different perspectives

Lets move on to the towers. Those follow the same basic rules as enemies, but have some more different properties to tweak. Here’s the example:
"id": 1,
"name": "Standard Tower",
"locked": false,
"unlockPoints": 0,
"configs": [
"image": "tower-1-lv-0.png",
"shotImage": "tower-1-shot.png",
"shotSound": "tower-1-shot.wav",
"shotCenter": { "x": 128, "y" : 90 },
"shotStartDistance": 90,
"damage": 1,
"radius": 1,
"slowdown": 0,
"shotDuration": 200,
"shotRecovery": 600,
"cost": 10
"image": "tower-1-lv-1-sprite",
"spriteCount": 4,
"shotImage": "tower-1-shot.png",
"shotSound": "tower-1-shot.wav",
"shotCenter": { "x": 128, "y" : 90 },
"shotStartDistance": 90,
"shotDuration": 200,
"shotRecovery": 500,
"damage": 1,
"radius": 1.3,
"slowdown": 0,
"cost": 5

Each config section describes an upgrade of a tower. If the player builds a tower, he’ll get the first config, upgrading the tower once will move on to the second config and so on. You can have as many upgrades for a tower as you wish.

Note that towers can have different shot types. You’ll find examples for all of them in the existing level pack. Note that the shot type has an impact on how the animation is played. This is probably the trickiest part and requires a bit of fiddling with the values to make it look good, but it offers a lot of different ways to model a tower and it’s capabilities.

The images work the same as for the enemies. You paint each animation frame in a 256×256 square and place them in a row.

A tower

You’ll need a different image file for each tower config. If you don’t want to change the look when a tower is upgraded, you can give the same image for multiple configs though.

Additionally you’ll need a shotImage. This needs to be a 64×64 pixel sized svg. For example:

A shot image for a tower

Make sure to continuously check the existing level pack. Many things for towers can be tweaked with properties that I can’t all list here. For everything that the game engine supports you’ll find and example in there.

Now, let’s create the first level. For each new level, create a sub-directory. Those sub-directories need to be named “levelX” where “X” is to be replaced by an increasing number, starting at 1. Each level directory needs to hold a file called level.json. The contents are as follows:

"startMoney": 150,
"rewardPoints": 20,
"board": {
"rows": 5,
"columns": 10,
"fieldsOnPath": [31, 41, 42, 43, 44, 34, 24, 14, 15, 16, 26, 36, 37, 38, 39, 29, 19],
"forbiddenFields": [0, 1, 10, 11, 12, 20, 21, 22, 30, 32]
"waves": [
"interval": 2000,
"enemies": [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22]
"interval": 1000,
"enemies": [1,1,1,1]
"interval": 1000,
"enemies": [1,1,1,1,1,1,1,1]
"interval": 1000,
"enemies": [1,1,2,1,1,2,1,2,1,1,1]

Let’s have a closer look at the properties. Start off with setting the start money and the reward points. The reward points will be given to the player when completing a level. They’ll be distributed depending on how many lives the player has left. Defining the board, you first set the amount rows and columns your field should have. FieldsOnPath is a list of fields where the enemies will walk along. They’ll follow the fields in the specified order. Make sure you specify fields that are next to each other.

Now the interesting part. Grouped into waves, you list the enemies that should walk across this level. The numbers point to the “id” in the enemies.json file. The interval specifies the time delay between the enemies entering the field. The reference is when playing on hard. For medium and easy, the interval will be made bigger by the game engine. So make sure you test your levels in “hard” mode to get the proper feeling.

Last but not least you need the background for the level. The graphic should reflect the path you defined in fieldsOnPath. To calculate the size for the image, use “columns” by 256 for the width and “rows” by 256 for the height. This will be the area that’s most visible to the player. However, the image should be bigger, double its size and fill the empty space around it with some neutral background. This will only be visible when the screen size doesn’t match the 256×256 concept and when zooming in on the level at the beginning. Here’s the example image:

That’s it. Your first level should be ready. Now you just need to compile it. For that, get a copy of lp:machines-vs-machines and copy your level pack into the data/levelpacks/ folder. Then execute ./ in the data directory. This will generate a ready to use level pack in the lpbuild folder. You can copy that folder into the data directory of an existing Machines vs. Machines installation, or build the game from the source you just checked out and run it in place.

If you create a level pack you can then build your own game package if you want. If your level pack is of decent quality, I’ll be happy to accept it into the official repository and publish it with an update of Machines vs. Machines.

And remember, hard is supposed to be hard.

Posted in Ubuntu | 8 Comments

OpenStore, TweakGeek and more

Now that the Ubuntu Phone is finally in the hands of many people, it’s time to get some hacking started! This is an attempt to bootstrap some hacking community around the devices that wants to explore the phone beyond of what the platform offers to the normal user at this time. To get this started I prepared an app, called Open App Store that allows hackers to install applications that can’t be published to the official store. This really is not about competing with the official Ubuntu store, but is meant as an extension for power users and developers.

Excited? Download the app here but think twice! This thing opens doors for possibilities to break your Ubuntu installation. Only install it if you know what you’re doing, install it at your own risk and make sure that you know how to reflash your device if you break something [1].

At this point you won’t find many apps in this store, but I managed to prepare two:

* TweakGeek: An app that allows you changing special settings of the device.
* Big Moving Text: You probably know this one from the official store. This version however, is able to keep your display lit while the text is running. Thanks to Michal Predotka for this contribution.

If you have an app that you’d like publishing in this store, here are the rules we’re gonna start with (those might change at some point but for now I think they make sense to see where this is going):

* If an application can be published in the official Ubuntu store, publish it there.
* If an application could be published in the official Ubuntu store if it wouldn’t be about that one cool feature, publish a stripped down version in the official store! Not everyone should and will have Open App Store installed.
* Only open source applications allowed: As the applications might have arbitrary access to the device, every submitted app will get a review and the source code is published along with the app.

Still on board? Here’s how you get started:
* Add an additional .apparmor file to your project (.apparmor.openstore) requesting the special permissions you need.
* Send me a link to a branch for your app to along with some instructions on how to build it if they differ from the standard (Ubuntu SDK).
* Give a short explanation why you can’t publish that in the official store. No need to go into details, a one liner like “needs to keep the display lit” will do. List all the special features you have, if there are more.

Looking forward to your contributions. For now the source code for the Open App Store can be found here. If you want to help out with developing the store app and/or the infrastructure behind it, ping me on IRC or drop me a mail.

Happy Hacking!


Posted in Ubuntu | 9 Comments

The reward of a loooong journey

Those who know me, and probably also those who followed this blog in the past, will know that I’ve been working in the mobile phone area for a long time now. Even before my time at Canonical, which is about 2.5 years now, I’ve been working for Nokia on a mobile phone platform that unfortunately never saw the light of day. So in total I think I’ve been working for close to 5 years now on getting a phone out the door.

And today it happened! A friendly man from DHL rang the doorbell about 30 minutes ago, handing me over the reason why I’m overly excited right now:

Now this device is a gift for my dad, who did a lot in supporting my way to be a software engineer, so I won’t turn it on right now to not destroy the joy of the first time welcome bells and whistles for him. And anyways, you can find a lot of pictures and videos of Ubuntu Touch out there in the internet by now.

Posted in Ubuntu | 5 Comments

Unity8 windowed mode

I’ve received requests from people asking how to try the windowed mode on their unity8 enabled devices (yes phones too). Here’s how it works:
You need a phone or tablet, flashed with the devel-proposed channel. On a PC, running an up-to-date vivid and having unity8-desktop-session-mir installed should get you going. Get a terminal on the device somehow (ssh/adb/terminal app) and execute:

gsettings set com.canonical.Unity8 usage-mode Windowed

While this currently works on phones too, there’s the issue that the window’s title bar is hiding behind the panel so you can’t really drag the windows around. Start the gallery-app to get around that. On larger screens, the panel should allow you dragging windows from there too. Here’s some screenshots:

Windowed mode on Nexus 4

Windowed mode on Nexus 4

Windowed mode on Nexus 7

Windowed mode on Nexus 7

Windowed mode on a PC

Windowed mode on a PC

To get back to staged mode, do:

gsettings set com.canonical.Unity8 usage-mode Staged

Again, this is still an early work in progress, loads of stuff missing in windowed mode. The gsettings flag is considered temporary and experimental, it might disappear at any time. Also, we might disable windowed mode on form factors where it doesn’t really make sense, like on the Nexus 4 screenshot above.

Posted in Ubuntu | 14 Comments

WhereTheIssAt redone

A couple of weeks back, I did a talk about how extend your QML application with a Qt/C++ plugin for the Ubuntu App Developer Week. The focus of this talk was really on how to write the QML and C++ code to make it work and I didn’t really get into the build system. As that was a live example I took – what I thought was – the shortest path to get something that compiles the plugin and I just created a new project with the UbuntuSDK picking one of the old style templates. That created a qmake project, and I just hooked that up to the Ubuntu QML app template somehow.

Today however, our master of the SDK (namely Zoltan) told me that there is a much easier way already which also provides seamless integration with the rest of the Ubuntu tools like click packaging and directly running it on the phone. Apparently that would have been available already back then, but I missed it. So in order to avoid other people missing out on this too I’ve updated the WhereTheIssAt example to use that template.

Here’s a quick walk through:

With the latest SDK, create a new project and select “Ubuntu -> QML Extension Library + Tabbed UI”

Once you’ve got that ready, you can jump straight into adding the Qt/C++ code. What I did is to drop the “mytype.cpp” and readd the “iss.cpp” from the previous project. Obviously that involves a small change in the backend.cpp, replacing “MyType” with “Iss”, but that’s it. A quick copy/paste of the wheretheissat.qml file replacing the generated TabbedUi sample code later, the project was again ready to run:

The biggest advantage (besides you not having to fiddle with multiple project files) is that it gives you click packaging for free. This is another big step for the SDK and makes it much easier to extent your QML app with Qt/C++ code.

I’ve pushed the code again here

Happy hacking!

Posted in Ubuntu | Leave a comment

Ubuntu App Developer week

Yesterday I did a tutorial for the Ubuntu App Developer Week. The topic was “Extending QML Applications with Qt/C++ plugins”. If you’re interested in that topic but you’ve missed the session, you can watch it here:

You can find the example code used in the tutorial on Launchpad.

Today I’m going to do a session about using qmltestrunner to test your QML applications. You can watch it live at 15:00 UTC at If you can’t make it, this site will keep the video for you to watch it later.

Posted in Ubuntu | 3 Comments

Shine for Ubuntu Touch released

Hey ya, using the UbBloPoMo as an opportunity to let you know that Shine has been released to the Ubuntu Touch App store.

Here’s a couple of screenshots:

Grab the source code from:

I’ve tried to keep the ColorPickers as generic as possible (i.e. it doesn’t depend on other shine code at all), so if anyone needs a color picker, you’ll know where to find it!

EDIT: here’s a more generic description of what it actually is:

Happy hacking!

Posted in Ubuntu | 3 Comments

Little sneak previews

Recently I’ve been busy working on the right edge gesture in Ubuntu Touch. Here’s a little sneak preview:

Note that this is still work in progress and probably won’t hit the image really soon.

If you’ve been paying attention while watching the video you might have noticed that I used Ubuntu Touch to control my living room lighting. That is done with a set of Philips Hue Lightbulbs which I got end of last year and a soon to be released app called “Shine”, running on Ubuntu Touch, MeeGo and Desktops.

Stay tuned!

Posted in Ubuntu | 15 Comments

Ubuntu SSO on Touch

Hey folks, it’s time to cross another app off the list of applications to be created for Ubuntu Touch. If you’re still relying on Google Authenticator to log in to your Ubuntu SSO account, you’ll be happy to hear that you can use your Ubuntu phone for that now. Ubuntu Authenticator can be used for the two factor authentication for Ubuntu SSO and other OATH-TOTP compliant two factor auth sites. It also features easy configuration by scanning QR-Codes using the camera.

Only event based (counter) authentication tokens are supported at present. Mainly because I only use two factor authentication with Ubuntu SSO and didn’t spend the time to search for a timer based authentication. But hey, as usual the app is free and open source software; If you are interested in contributing support for the timer based auth method, let me know.

The app is submitted to the Ubuntu Store and pending review. It should be available for you to download soon.

Source code at:

Posted in Ubuntu | 3 Comments