It’s been quite a while since I had written a post now. Lots of things have changed around here but even though I am not actively developing for Ubuntu itself any more it doesn’t mean that I’ve left the Ubuntu and FOSS world in general. In fact, I’ve been pretty busy hacking on some more free software goodness. Some few have sure heard about it, but for the biggest part, allow me to introduce you to nymea.
nymea is an IoT platform mainly based on Ubuntu. Well, that’s where we develop on, we provide packages for debian and snaps for all the platforms supporting snaps too.

It consists of 3 parts: nymea:core, nymea:app and nymea:cloud.
The purpose of this project is to enable easy integration of various things with each other. Being plugin-based, it allows to make all sorts of things (devices, online services…) work together.

Practically speaking this means two things:

– It will allow users to have a completely open source smart home setup which does everything offline. Everything is processed offline, including the smartness. Turning your living room lights on when it gets dark? nymea will do it, and it’ll do it even without your internet connection. It comes with nymea:core to be installed on a gateway device in your home (a Raspberry Pi, or any other device that can run Ubuntu/Debian or snapd) and nymea:app, available in app stores and also as a desktop app in the snap store.

– It delivers a developer platform for device makers. Looking for a solution that easily allows you to make your device smart? Ubuntu:core + nymea:core together will get you sorted in no time to have an app for your “thing” and allow it to react on just about any input it gets.

nymea:cloud is an optional feature to nymea:core and nymea:app and allows to extend the nymea system with features like remote connection, push notifications or Alexa integration (not released yet).

So if that got you curious, check out https://wiki.nymea.io (and perhaps https://nymea.io in general) or simply install nymea and nymea-app and get going (on snap systems you need to connect some plugs and iterfaces for all the bits and pieces to work, alternatively we have a ppa ready for use too).

I’ve published this earlier as google doc, but it seems that was a bad idea and many people are still asking the same question. So here’s the same howto, targetting a somewhat broader audience:

Please note: This is not officially supported yet but has been tested by a fair amount of people by now. All steps are taken at your own risk. Be prepared to reflash the tablet if you mess up. Also note that none except the preinstalled applications have been tested by Canonical. Your favorite application might just not work yet.

Update: As people pointed out in the comments (thanks for that!), this will fail if ran from the Terminal app on the device. Instead, use a USB cable and log in to the tablet using phablet-shell from the package phablet-tools and run the following commands from there.

Initial setup
First we need to replace the link to the container config with the actual container config so it can be edited.# cd ~/.local/share/libertine
# rm ContainersConfig.json
# cp /custom/click/.click/users/@all/com.ubuntu.puritine/libertine-config/libertine/ContainersConfig.json .

Now we have a second container in the writable part of the image named puritine2. The original that comes preinstalled (named puritine) is still there, but in the read-only part of the image.

Installing applications in the new container
First we fire apt-get inside the container to install inkscape. The libertine-container-manager can do that all for us. In this example, we’re installing inkscape.# libertine-container-manager install-package -i puritine2 -p inkscape

Nearly done. All that’s left to do is to add an icon in the dash so we can actually launch inkscape. For that we copy the preinstalled gimp icon and edit it to launch inkscape instead. Note that the naming of the file is key here. The file name consists of containerid_appid_version.desktop. So in our case puritine2 for the container id, inkscape for the appid and well, the version seems to be unused at this point, so let’s leave that at 0.0.# cd ~/.local/share/applications/
# cp /usr/share/applications/puritine_gimp_0.0.desktop puritine2_inkscape_0.0.desktop

Now edit the file and change the Name= field to say inkscape and the Icon= field to point to an icon you want. Don’t edit any other fields.
Now pull down the apps scope to refresh it. Inkscape should appear there and start up when you click it.

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.

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.

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.

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.

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.

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.

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:

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:

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 ./setupdata.py 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.

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 michael.zanetti@ubuntu.com 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.

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.

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 7

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.

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.

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.

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: