Donnerstag, 29. Januar 2015

Running Debian sid on Sailfish OS

This assumes you have a Debian/Ubuntu host computer on which to run debootstrap. Theoretically you can run this on the device, but it's not as easy as on Harmattan (where you can just install the debootstrap package. On the host, run the first init and create a tarball:
    sudo debootstrap --arch armhf --foreign sid sid
    sudo tar czvf sid.tgz -C sid .
    du -sh sid.tgz 
    # 98M     sid.tgz
    scp sid.tgz nemo@
To unpack the chroot tarball:
    ssh nemo@
    # password

    mkdir sid
    cd sid
    tar xvf ../sid.tgz
    chroot /home/nemo/sid/ /debootstrap/debootstrap --second-stage
    chroot /home/nemo/sid/ apt-get clean
    echo "deb sid main" \
To enter the chroot:
    ssh nemo@
    # password

    mount --bind /proc /home/nemo/sid/proc
    mount --bind /sys /home/nemo/sid/sys
    mount --bind /dev /home/nemo/sid/dev
    mount --bind /dev/pts /home/nemo/sid/dev/pts
    cp /etc/resolv.conf /home/nemo/sid/etc/
    chroot /home/nemo/sid/
    apt-get update

Samstag, 19. April 2014

My N9 apps and games now self-hosted and on

As the versions of my apps on Nokia Store grow more and more outdated, I've decided to remove the apps from there and instead self-host them on my web page and/or put them on instead. A handful of apps stay on Nokia Store; those are mostly S40 apps or apps for which a Symbian version also exists.

Here's a list of my N9 apps that you can now get for free ("deb download" is as of posting this, for new versions visit the webpage or
And here's a list of my N9 games that you can now get for free (again, "deb download" is as of posting this; new versions on the webpage or
Of these, the "greatest hits" and most useful apps/most fun games are (in my opinion): Billboard, Volume+ As Camera Button and chro.mono, but also give qw The Game and Petals a try :)

A list of all my apps on is also available.

Please note that unless otherwise noted, do not copy the .deb files and distribute them yourself, please always link to the project webpage (the page, not the file) or the page - this makes sure users can always download the latest version and from a known-good source (always be careful when downloading and installing .debs from random webpages). For end users who want to stay up to date and install the packages comfortably, the Warehouse client for is recommended.

For some of these apps (not games) that are not open source yet, I plan to clean up and publish the source at some point in the future, so interested developers can have a look, add features and/or port it to new platforms.

Samstag, 15. März 2014

gPodder 4.0.0 for Sailfish OS released

While we're supplying N9 users with fresh releases of gPodder 3 regularly (the latest version, 3.6.1, has been released last week, and the update is available on, of course we've also been busy working on a newer, Qt 5 and PyOtherSide-based version of gPodder. After weeks of testing, I think it's good enough for a first release now, so let's warmly welcome gPodder 4.0.0 to the world of Sailfish apps. You can download it and its dependencies from the gPodder downloads page.

If you haven't read last year's article about Python and Qt 5, now might be a good time to do so. PyOtherSide is a much more minimalistic approach to Python bindings, and - in my obviously biased opinion - works better for gluing together a QML UI with a Python backend. In fact, it lends itself to clearly splitting the frontend from the backend, and with the "asynchronous by default" design, you have to work really hard to block your UI thread with long-running Python code (or multithreaded Python code that's waiting for the GIL to be released). PyOtherSide these days is also well-documented, and some early annoyances and bugs have been fixed with recent releases in February. In combination with Qt 5 and Python 3, it works well on OS X, Blackberry 10, Linux, Sailfish OS and Windows. With Qt 5.2 having official support for Android, and a Python 3 port being available, it's only a matter of time before PyOtherSide lands on Android.

For all Sailfish OS users out there: Until the next Sailfish OS update, you might have to install some dependencies before gPodder will correctly start up, these are:
  1. libpython3 (the Python 3 interpreter)
  2. python3-base (the Python 3 standard library)
  3. pyotherside (the Qt 5-Python3 bindings)
As these links point to the current version in OBS, they will break once one of these packages is updated. In this case, just look into the home:thp:gpodder armv7hl repository for the latest versions of these packages. With the next Sailfish OS update, recent-enough packages of PyOtherSide should be in the repositories, so you don't need to install the dependencies manually.

Donnerstag, 18. Juli 2013

The way forward with Python on Qt 5 (with a bit of history)

As you have probably heard on Twitter from the official Jolla account, the first Jolla will ship with Wayland. In that discussion, some worries are brought up about Python support with Qt 5. Here are my personal thoughts of how I see mobile Python development moving forward with the new technology. So first some background information:

If you want to write Python applications on a mobile platform, you usually need some way to interface with the native graphical toolkit. On Maemo 4 and Maemo 5, this was done via PyGTK and some additional bindings for the Hildon UI elements. PyGTK is licensed under the terms of the GNU LGPL, so you could use it to develop open and closed source applications.

When MeeGo 1.2 Harmattan (the system running on the N9) came up, the toolkit with which third party application developers wrote their applications changed from Gtk to Qt (or to be more precise, QML). Just like pure Gtk didn't provide all the UI elements for mobile (and therefore Hildon was used on top of Gtk), pure QML provided very little, and so Qt Quick Components were used for the Harmattan user interface (that includes things like buttons, toolbars, menus, dialogs, etc...). These could only be used from QML, so you had to use QML if you wanted your application to look anything like native (ignoring the MeeGo Touch Framework here, as it wasn't really used for third party apps, with the notable exception of sociality-mtf).

With Qt and QML being the new toolkit of choice, Python developers needed a different "bridge" to go from the Python world to the toolkit world. PyQt already existed for some time then, it had two license options: GNU GPL (basically requiring all your code that uses PyQt to also become GPL'd) and commercial. As the Wikipedia article of PySide says, after Nokia failed to reach an agreement with Riverbank Computing (the developers of PyQt) to change the license to LGPL, they started their own Python bindings named "PySide", which are licensed under the terms of the GNU LGPL. There's a wiki page with PySide-PyQt differences on the Qt Wiki.

As MeeGo at Nokia was ramped down, the core team of PySide had less and less time to spend on improving it. PySide is still kept up to date (the latest release is from July 9, 2013), and it already supports Python 3, but nobody has yet ported it to Qt 5. The most recent post I found about PySide and Qt 5 from one of the core developers was from November 2011. For using Python with Qt 5, there are two possibilities at the moment: Use PyQt under the terms of the GNU GPL, or get a commercial PyQt license. Another option to get LGPL'd bindings would be to add support for Qt 5 to PySide, but that needs somebody to adapt PySide to work with Qt 5.

But let's step back a little now. In my experience with writing Python applications for mobile operating systems (starting with Maemo 4 all the way to MeeGo 1.2 Harmattan), there are really two parts: The frontend, which is specified in terms of whatever the toolkit of the day happens to be, and the backend, which (in case of Python applications) is written in Python.

In Qt 5 / QtQuick, the user interface language is QML, which includes a declarative language and JavaScript for scripting. Writing QtQuick applications with Python doesn't mean replacing JavaScript, it means replacing the "backend" - code that would usually be written in C++ and take care of storage and communication. In fact, as QML grew more powerful over the years, you had to "go down to the C++ level" (or Python in our case) less often. And compared to imperative user interfaces (where you still go through your tree of UI widgets with code and then set some button text to some value), in declarative user interfaces the backend really only provides services to the frontend (that button gets the label from the backend in this way, and when the data in the backend changes, so does the button's text).

So, what we really need is a way to provide services to the QML UI by using Python. There's no need for having access to all classes in all Qt modules - even in Qt4 / PySide times, the classes that I used most often were QApplication (for the event loop), QDeclarativeView (for displaying the QML UI) and QObject (for providing signals and slots to interface the backend to the view). Things like access to the contacts database or GPS location can usually be done directly from QML (and displayed there) - it might be that you don't even need to have that data in your backend (and if you do, the UI can for example send the phone number of the contact "down to" the Python backend for further processing).

But before I'll tell you where I think mobile Python development should be heading, let's bring up yet another disadvantage of using PySide (probably applies to PyQt as well) for mobile applications: Startup time and responsiveness. Startup time is slow, because PySide libraries are big (they are - at least on the N9 - bigger than the Qt libraries they are binding), and the dynamic linker has to resolve all Qt symbols at load time instead of just the ones you end up using. Instead of seeing the QML UI right away, your application first has to load up the Python interpreter, then load up the PySide modules and other modules and then finally load and display the QML UI. And because of Python's Global Interpreter Lock, function calls from QML to Python will make the UI block and not be totally responsive, even if you are using threads.

So, in my opinion, mobile Python applications with Qt 5 have to be fast to load, lightweight and responsive. Fast to load can be achieved by making sure the libraries that get loaded are small, and that ideally the QML UI can already be displayed before the Python interpreter is even loaded and/or initialized. Lightweight can be achieved by not binding all the Qt classes, but only the ones you really need for creating QML applications. And responsive can be achieved by making sure that the interface between QML and Python is asynchronous, so the UI never blocks even if Python is working hard in the background to fulfill the requests of the user interface.

I currently have a prototype running on Python 3.3 (Python 2.6 and 2.7 is also supported still, but for me, this is a great opportunity to migrate some of my old code to Python 3, and new code should be written in Python 3, because, as you know, Python 2 sucks) and Qt 5 (I've just ported it to Qt 5 today, but it runs just as well on Qt 4 - with all the advantages like startup time and asynchronousness still being valid). In some unscientific tests that I carried out a few weeks ago, I've brought down startup time of gPodder on the N9 down from ~ 12 seconds (using Python 2 and PySide) to ~ 3 seconds (using Python 3.3 and the lightweight "PyOtherSide" approach). No code release yet, as this is tailored towards my gPodder experiment right now and has many things hardcoded, but once I clean it up (maybe as a QML plugin) and define the API in more detail, I plan to release it.

In the mean time, here are some (relatively old) videos of PyOtherSide running with Python 3 and Qt 4 on MeeGo Harmattan, Blackberry 10 and Android (so yes, it is portable).

Donnerstag, 16. Mai 2013

Behind the Scenes: Headset Camera app for the N9

The logical step after the "Volume+ as Camera Button" app (Nokia Store link) for the N9 is another app that allows you to take photos while not touching your N9 at all. While time-triggered photos are fun, remote-triggered photos are.. erm.. "funner"? So what kind of remote "buttons" can we easily get on the N9? The remote control button on the headset is both "remote" and a "button". Also, as seen in Panucci and gPodder versions since the N900, Bluetooth headset buttons can also be queried by applications. So what do we get by combining remote control and photo taking? The Headset Camera app (Nokia Store link) for the N9! Or - for the visual reader - this:

If you want to integrate such features into your own app, the code for querying the headset buttons is readily available in the gPodder source tree (src/gpodder/qmlui/
import dbus

class MediaButtonsHandler(QtCore.QObject):
    def __init__(self):
        headset_path = '/org/freedesktop/Hal/devices/computer_logicaldev_input_0'
        headset_path2 = '/org/freedesktop/Hal/devices/computer_logicaldev_input'

        system_bus = dbus.SystemBus()
        system_bus.add_signal_receiver(self.handle_button, 'Condition',
                'org.freedesktop.Hal.Device', None, headset_path)
        system_bus.add_signal_receiver(self.handle_button, 'Condition',
                'org.freedesktop.Hal.Device', None, headset_path2)
    def handle_button(self, signal, button):
        if signal == 'ButtonPressed':
            if button in ('play-cd', 'phone'):
            elif button == 'pause-cd':
            elif button == 'previous-song':
            elif button == 'next-song':

    playPressed = QtCore.Signal()
    pausePressed = QtCore.Signal()
    previousPressed = QtCore.Signal()
    nextPressed = QtCore.Signal()
MediaButtonsHandler is already a QObject subclass, so you can easily expose an instance of this class to your QDeclarativeView rootContext() and connect to the signals in QML (such a "headset button handler" might actually be a good candidate for inclusion into nemo-qml-plugins in Sailfish OS and Nemo Mobile?). As it's really just using the Python D-Bus bindings to get property changes from Hal devices, the code above should be easy (read: trivial) to port from Python to Qt/C++. Be aware that you need to connect to both .../computer_logicaldev_input_0 and .../computer_logicaldev_input, which can both exist if you have a cable headset and a Bluetooth headset connected at the same time.

You can get the Headset Camera App for the N9 in Nokia Store now, there is also a video on YouTube showing the app. Or start integrating headset button features into your own app or scripts by adapting the code above. One use case that comes to mind is using the previous/next buttons on a Bluetooth headset to control a photo slideshow on the N9 connected to TV-Out. Enjoy :)

Dienstag, 14. Mai 2013

HTML5 Web Apps on Mobile Devices

Get out your Buzzword Bingo cards, we're talking HTML5. And Canvas2D. And WebGL. See? Check them off and then continue reading. So, while writing "native" apps using JavaScript is definitely possible and works great with QML, some games are just simple enough (or want to have a broad enough audience) to warrant writing everything in HTML5.

This might also be a good time to check off XmlHttpRequest on your BB card, even if none of the following games use it - you might want to use it in your applications or game for things such as server-side stored high scores.

As far as Maemo and MeeGo is concerned, you might want to try out some of these games (especially the WebGL variant of One Whale Trip) in Fennec (aka Mobile Firefox - get it for: N900, N950/N9, Nemo Mobile).

Color Lines: This one simply uses Canvas2D, and works nicely on all mobile browsers that I tested - Maemo, MeeGo, Android, WP7.5, BB Playbook, iOS. Comes in at about 650 lines of rather well-documented JavaScript, and could easily be ported to use QML as a renderer if need be (it would be good to have a QML Plug-In that provides a JavaScript context + (a subset of) the Canvas2D API - without using WebKit (cross that off, too), that is). Also, the N900's stock browser has performance problems rendering this, while on the same device in Fennec it's quite playable.

Circle1D: This is a straight Python-to-JavaScript port of a lame 2D "Physics" Engine. It's kept very (read: very, very) simple, and collision detection could be done in a nicer way, but the inefficiency of it provides a nice benchmark for comparing JavaScript engine performance (I'm sure you can find "engine performance" on your bingo card as well) on mobile devices. The N900's default browser can't handle it at all, but Fennec can at least render/simulate it, albeit slowly.

One Whale Trip: This game actually started out as a Python game for PyWeek last September, which was also ported to the N950/N9, but as a test for trying out WebGL, I decided to port it from Python/PyGame to JavaScript/Canvas2D and then to WebGL (the Python version also contains two renderers - a "blitting" one using PyGame surfaces, and an OpenGL one using OpenGL [ES 2 on mobile]). The Canvas2D version works again in all modern mobile browsers (same as above), the WebGL only works on browsers supporting WebGL, for example Fennec/Firefox on both the N900 (even though very slowly) and not in any of the stock browsers (even not the one on the N9). As WebGL is "roughly" the same as OpenGL ES 2.x, one could imagine sharing at least shader programs for a possible C++-or-JavaScript cross-platform application.

So yeah, for smaller applications and/or games, HTML5 is definitely an option. In Firefox OS, your HTML5 web app will - also with WebGL - work and integrate nicely as "native" app. If you also want to create "native" applications (maybe after finishing the HTML5 version), consider encapsulating your JavaScript code so that you can re-use it in QML code, or (in case of WebGL apps), at least design the rendering part of your application in such a way that the code/architecture and shader programs can be shared with a C++ port of your existing HTML5 app.

Another option that's worth considering: Writing a compatiblity application layer that can load (specially-crafted) WebGL subset applications and display them on a fullscreen SDL-(or Qt)-provided window. Applications written in this WebGL subset could then be deployed on the web as HTML5 application or "natively" running on top of a JavaScript engine only. I'd call that "webglenv", and no, I haven't written it yet.

Sonntag, 12. Mai 2013

Petals for Harmattan - A pure Qt4/Qt5 JS/QML puzzle game

Next up in my list of things I did in the last weeks/months and never blogged about is Petals (Nokia Store link), a "beautiful, brain-teasing puzzle game for 1-4 players" if the game's website is to be believed (I would like to think it is...). As always, there's some technical details about the porting and creation of this game. While another recent game (Tetrepetete) has been done on a low level (C++ using no frameworks, and interfacing with multiple front-ends directly, including an OpenGL ES frontend, a console-based ncurses frontend(!) as well as a server-sent events/XHR/Canvas2D-based HTML5 frontend(!!)), this one is approaching things from a very high level: JavaScript.

Petals: A puzzle game written in pure JavaScript and QML
The gameplay logic of the game is implemented in pure JavaScript (without any QML dependencies), so it could easily be ported to, say, HTML5, but for integration reasons, QML seemed like the better choice for a release on the N9/Harmattan. Also, writing things in JavaScript wouldn't preclude a console-based frontend using nodejs and node-ncurses from happening should the need arise (making the flowers look good in ASCII art would be the challenge there - or cheating by using libcaca). Ok, ok - stop cursing, I'll stop talking about curses (cue laugh track).

Writing pure QML applications has the advantage of easing porting to Qt 5. While QtQuick 1.1 still exists on Qt 5 (and is the only QML option at the moment if you are also targetting iOS), QtQuick 2.0 is usually the better choice for performance reasons.

In my case, the changes necessary to port from QtQuick 1.1 to QtQuick 2.0 were:
  • Change "import QtQuick 1.1" to "import QtQuick 2.0" (sed(1) helps here)
  • Instead of assigning a JavaScript function to a property to create a dynamic property binding (item.someprop = function() { return otheritem.otherprop * 3.0; }), this function has to be wrapped in a call to Qt.binding() in Qt 5 (see "Creating Property Bindings from JavaScript" in the Qt 5 docs)
  • Instead of using SQL Local Storage directly as in QtQuick 1.1, use QtQuick.LocalStorage 2.0, which you can still do in your .js files - use ".import" as described in this blog post
  • In your C++ launcher (in case you need one), QApplication becomes QGuiApplication, and QDeclarativeView becomes QQuickView
  • Use "QT += quick qml" instead of "QT += declarative" in your qmake project file
And that's basically it. Of course, as this is a full-screen game with custom UI, no platform-specific components (such as Harmattan Components or Sailfish Silica) are used, so porting is a bit easier there (no need to "wait" for specific components to be compatible with QtQuick 2.0, which might realistically not happen at all for Harmattan Components). More screenshots of Petals and download links for multiple platforms can be found on the Petals Website.