This depends on Bounce (the N900 .deb) and SDL 1.2 being installed. Google "bounce_1.0.0_armel.deb" for the former, and use n9repomirror for the latter.

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@192.168.2.15:

To unpack the chroot tarball:

    ssh nemo@192.168.2.15
    devel-su
    # 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 http://http.debian.net/debian sid main" \
        >/home/nemo/sid/etc/apt/source.list

To enter the chroot:

    ssh nemo@192.168.2.15
    devel-su
    # 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

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 OpenRepos.net 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 openrepos.net):

• Billboard Standby Screen (web page, deb download, openrepos.net)
• Volume+ As Camera Button (web page, deb download, openrepos.net)
• Headset Camera Button (web page, deb download, openrepos.net)
• Personal Web Server (web page, deb download, openrepos.net)
• Mustr (web page, deb download, openrepos.net) 
• gPodder (web page, deb download, openrepos.net)

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 openrepos.net):

• qw The Game (web page, openrepos.net)
• Tennix! Redux Demo (web page, deb download, openrepos.net)
• Petals (web page, deb download, openrepos.net)
• Brain Party (web page, openrepos.net)
• Numpty Physics (web page, openrepos.net)
• Plonk (web page, openrepos.net)
• chro.mono (web page, deb download, openrepos.net)

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 OpenRepos.net 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 openrepos.net 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 OpenRepos.net 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.

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 gpodder.org/downloads), 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.

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:

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/helper.py):

import dbus

class MediaButtonsHandler(QtCore.QObject):
    def __init__(self):
        QtCore.QObject.__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'):
                self.playPressed.emit()
            elif button == 'pause-cd':
                self.pausePressed.emit()
            elif button == 'previous-song':
                self.previousPressed.emit()
            elif button == 'next-song':
                self.nextPressed.emit()

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

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.

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

Turns out I haven't posted here for two months, so here we go again: Billboard, your favorite low-power mode standby screen will soon receive a new update - version 1.0.9 has been uploaded to Nokia Store QA two days ago, and should hopefully pass QA and be available as an update in the next few days. This release brings a few major under-the-hood improvements and small bugfixes:

• Fixed MeeCast icon (in 1.0.8, you can already use <<{meecast-icon-src}>>)
• New formatter that allows you to nest {} expressions used for adding dynamic content
• Optional image dithering (using # after the filename) for better colors in low power mode

With the new formatter, you can now output {} expressions in your scripts so that they get replaced, and similarly pass {} expressions as parameters to your scripts (for example to modify them in some way before displaying). This should allow for even more customization, some examples of what users have been doing on their N9 standby screen can be seen in the Billboard Standby Screen support thread on talk.maemo.org.

If you are looking for additional ways to tweak and enhance your Billboard-on-N9 experience, have a look at billboard-scripts, a growing collection of Shell and Python scripts that provide even more ways of customizing your standby screen.

If you haven't purchased Billboard from Nokia Store yet, you can get the current version now for your N9, and get the upgrade to 1.0.9 as soon as it's available. If you are already a happy user, watch your application updates in the next few days, and get the new version.

So the Sailfish SDK was released last week, and as explained in the last blog post, gPodder is already running on Sailfish Silica Components. Of course, this has only been possible because Silica is quite similar in API design to Harmattan Qt Components (whenever I write "Harmattan" in this blog post, I usually talk about Harmattan Qt components, and whenever I write "Sailfish" it usually means "Sailfish Silica Components"). But of course porting "from" Harmattan "to" Sailfish with no way back would be kind of annoying - either Harmattan gets dropped, or somebody has to maintain two codebases, something I'd rather avoid. So, just like in "good old" Maemo 4 and Maemo 5 times, the goal here is to convert a Harmattan-only codebase to Harmattan-and-Sailfish, so that both can be maintained in the same codebase and improvements to Harmattan benefit the Sailfish port and vice versa.