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

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.

Porting Harmattan Apps to Sailfish Silica (and back)

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.

In fact, while porting gPodder from Harmattan to Sailfish, it reminded me of porting from Maemo 4 to Maemo 5 - same toolkit (then Gtk+, now Qt/QML), similar extensions (then Hildon, now Components) but different concepts (then normal menus in Maemo 4 vs. HildonAppMenu in Maemo 5, now toolbars and context menus in Harmattan vs. pulley menus in Silica).

Obviously, as gPodder is written in Python here, this applies mostly to PySide-based applications, but the real difference is in the QML (there's really only one short snippet in the Python code that decides which QML import path to use). The approach taken is somewhat simliar to what the Jolla guys have been presenting at FOSDEM 2013, but I don't recall everything and have tailored the approach to better fit my workflow.

Before we start, be sure to know that qt-components is in the Sailfish Emulator (once you install it via "zypper in qt-components" as root), so that could be a shortcut for quick porting exercises and as an interim solution.

For starters, I've cleaned up gPodder's QML UI to make better use of Qt Components (historically, gPodder's QML UI was started at a time where Harmattan Qt Components were not even out or announced, so wazd and me came up with our own style - yes, that's pre-feb11 even!). So, instead of custom transitions and state management, everything is a Page, and transitions happen via the PageStack (the Silica equivalents are also called Page and PageStack). So, assuming you only have pages and so on, you could theoretically already use this or that depending on which platform you are on. Unfortunately, QML doesn't have conditional imports or something like that, so we have to add some abstraction layer.

Here's the basic idea:

1. Create a new "Components" set - I'm calling mine "org.gpodder.qmlui"
2. You define which items your components have, and a common API
3. You implement your components twice: Once for Harmattan, once for Sailfish
4. At runtime (or even compile time if you would want that) you decide which set of components you use
5. Your application GUI code only imports QtQuick, maybe QtMultimediaKit (if you need it - it's available on both platforms) and your custom components (org.gpodder.qmlui in my case)

Just in case you are already running to the gPodder Git repo now to check it out, here's a short disclaimer: The UI isn't fully ported yet, so there's still a few remaining "com.nokia.meego" (Harmattan Qt Components) imports in my QML UI, but that's just temporary until I have found a good replacement for things like Sheet and MultiSelectionDialog in Silica.

My custom components at this time look like this:

• Harmattan implementation of org.gpodder.qmlui (as of gPodder 3.5.0)
• Sailfish implementation of org.gpodder.qmlui (as of gPodder 3.5.0)

Most of these are just thin wrappers around the "native" components on the target platform. For example, WindowWindow.qml (harmattan, sailfish) is just a wrapper for PageStackWindow (on Harmattan) and ApplicationWindow (on Sailfish). Where I said "import com.nokia.meego 1.0" and "PageStackWindow {}" previously, I now say "import org.gpodder.qmlui 1.0" and "WindowWindow {}". In the case of the Harmattan implementation, this is just the same as before, but on Sailfish, an ApplicationWindow will be used.

Other wrappers just deal with API differences. For example, ScrollDecorator exists in both Harmattan and Sailfish, but in Harmattan the property is called "flickableItem" and on Sailfish it's "flickable". So my ScrollScroll (harmattan, sailfish - also, noticed a naming pattern there? ;) takes care of hiding the differences, and I just use "flickable" on a ScrollScroll, and it will do The Right Thing on the platform it's currently running on.

When the API is the same (e.g. for Button), you still need to create pass-through components because of the different import path: Button (harmattan, sailfish).

But there's also some more elaborate differences. For example, I want to have menus - a toolbar menu on Harmattan and a pulley menu on Sailfish. So I defined a very simple Action (I'd be surprised if such a component doesn't already exist, but I didn't find one when I wasn't looking (sic)) that basically has a text and some signal attached to it. In my application code, I define actions as a property on my PagePage (which is a Page with some special code to transform actions into whatever the platform representation is). See the main page actions for an example. The ActionMenu (harmattan, sailfish) then takes care of creating a ContextMenu (Harmattan) or PullDownMenu (Sailfish) and PagePage (harmattan, sailfish) takes care of creating a toolbar on Harmattan and forwarding a reference to the listview to which the PullDownMenu should be attached to (in Harmattan, I still need to pass the listview there, but it's not used).

The same customization also happens for the ListList (harmattan, sailfish), which is a ListView (Harmattan) or SilicaListView (Sailfish), but also takes care of displaying a header (which still needs to be styled correctly on Sailfish) if the platform requires it.

Once you've created your custom set of components, you have to create a qmldir file that lists the components available and in which version of the components they are available. Read up on Declarative Modules in the official documentation.

So there you have it. One QML codebase, two UX targets that are well-integrated. You can see the results in the just-released gPodder 3.5.0, which is more Harmattan-ish on the N9 than before (although some items have moved from the toolbar into the menu for simplicity reasons, and I actually think it's cleaner now) and also looks and feels quite native on Sailfish (it's not done yet, and I'm sure the UI will evolve and adapt once Silica gets more mature and we see more Sailfish apps).

What I'd like to see in the Sailfish SDK: Different Ambiance backgrounds (darker, brighter, different hues) so that developers like me can test if their apps look good atop more than just the nice blue default background.

As a last hint (I couldn't find that in the API docs, but in the component gallery): Sailfish Silica's Label Component has a "truncationMode" property. If you set it to "TruncationMode.Fade", you never want to see elided text again, because it looks so sexy! :)

qw The Game ported to Android

I decided it's time to port qw The Game to Android, as a way to see how the publisher story works on Google Play compared to Ovi Publish and also to see how mature the Qt port to Android is.

For my port, I used Necessitas alpha 3 update 4, which you can download from the project website. Necessitas already includes both the Android SDK (that's the SDK you use in general, and contains all the Java APIs, etc..) and the Android NDK (that's used if you want to do native C/C++ development), so no need to install anything else. You can start Necessitas Qt Creator using "QtCreator/bin/qtcreator" in the Necessitas installation directory, but Necessitas also creates a launcher icon if you shy away from command lines.

The assumption is now that you have an existing Qt project with a qmake project file (.pro). Just open that .pro file in Necessitas Qt Creator and let it create the Android scaffolding. You can now try to build the project and run it - either in the Android emulator, an actual Android device or your N900, N950 or N9 running Nitdroid (the N950/N9 port is actually quite nice these days, and can be installed alongside Harmattan by flashing an open mode kernel with Android patches, replacing some init files and placing the Nitdroid rootfs inside /home/nitdroid/).

When you first start a Qt-based application on Android, it will redirect you to Google Play to download Ministro, which will take care of downloading the Qt libraries and storing them in a central, shared place, so that all Qt-based apps can use the same Qt libraries (which means that you can do closed-source apps, because they are dynamically linked to the LGPL'd Qt, and it also means that apps are smaller, because Qt doesn't need to be shipped with each app). One disadvantage is that the end user experience is not seamless on first startup, because your users will have to install Ministro first and wait for the Qt libraries to download.

Anyway, now you got that far and got your application running - or not. If you are missing libraries, and your application doesn't start, open the "Projects" tab in Necessitas Qt Creator and click on the "Run" tab for the Android target. There, open "Package configurations" and click on "Libraries" and check all Qt libraries that you need. When you compiled your application, there's a button ("Read information from application") that will analyze your binary and check the right Qt libraries. You can also add "Prebundled libraries", which are dynamically-linked shared libraries that will be shipped with your application. You can also check out the "Manifest", "Application" and "Permissions" tabs and configure it to your liking.

Protip: You can build the Android package on the command line using "ant" as soon as you have used Necessitas Qt Creator to create the initial scaffolding. The "android" folder will be created inside the folder where your .pro is located, and there you will find a build.xml.

Now to some code-level customizations that I had to do for my game, qw:

• QtMultimediaKit was not found - I had to comment out sound effects for now
• Automatic screen rotation - My game is landscape-only, and I had to tell the Android system in the AndroidManifest.xml file
• Qt.labs.particles was not found - Again, I simply commented it out for now; I guess these QML plugins should be easy to add to Necessitas, but I didn't bother to find out for this first try
• Screen resolutions! - Don't assume 800x480 (in case of the N900) or 854x480 (in case of the N950 and N9); make your app scale properly to the screen resolution at hand. Test this by creating a non-fullscreen window on your Desktop in different sizes, and see if the content looks right. For a quick'n'dirty first try, use QGraphicsView::scale

As far as the publishing experience goes: You have to pay a one-time fee of $25 to be allowed to publish to the Play Store (compare this to a one-time fee of 1 Euro for Ovi Publish and a yearly fee of $99 for the iOS App Store). What I found interesting is that there's basically no QA (apart from automated checks that are very helpful and give guiding error messages) and an application uploaded is published in a matter of minutes. I also like the fact that you can add a YouTube video link to the Play Store submission, so users can get a preview of how the experience is like. I published the app for free, and the UI warned me that it's not possible to convert a free app into a paid one in the future, which doesn't matter for me, but it might be a useful hint for other publishers.

qw The game is now available on Google Play for free. It's also available in Nokia store for free. Go play!

gPodder/QML on the N900 - Yesteryear and today

I just found this pre-feb11 gPodder/QML on a N900 on 2011-02-04 video and someone on TMO recently asked me about the status of gPodder for the N900, so I thought I'd try the current version of gPodder on the N900.

The result is a new video of gPodder/QML on a N900 today, which shows what works and what does not.

If you want to try it yourself, get the latest CSSU for your N900 and enable Extras-Devel (the usual disclaimers apparently still apply). Now, make sure to install all of PySide and Qt Mobility 1.2, and the packages qt-components and qt-components-blanco-theme. The theme package is broken right now, so you need to copy /usr/share/themes/blanco/meegotouch from a Harmattan device or the Harmattan SDK onto your N900 manually. When you have done that, simply checkout gPodder (master branch) from its Git repository.

What doesn't work yet:

• Text input fields are missing their backgrounds
• Screen rotation doesn't work (Qt Components bug?)
• Task switching is only possible with Ctrl+Backspace

Apart from these annoyances (and the problem with the missing blanco theme files), everything else works as one would expect. If these problems get fixed (so that all dependencies are readily available from Extras-Devel), I might be able to make some time to package gPodder 3 for the N900.

Harmattan (N9/N950) users: Have a look at the video to see how the play queue and episode list filters work, which will land in a new gPodder release "soon".

Games (and their backstory) for your N9, N900 and N950

I've recently been asked again about the games I wrote for mobile devices, so here it is: The post with an overview of the games, with some not-so-well-known backstories and information on where to get them for different devices. Plus a little teaser hidden somewhere.

Gaberln (N950, N9 (+Symbian): Ovi Store, N900: Maemo Talk)
This game is a simple soccer ball juggling game - developed using QML, in collaboration with Tim Samoff, who did the great artwork (and who also did the Mong artwork) - we still have to add some more features, and Tim has already done the graphics for a special hacky sack mode, let's hope we get around to finishing it at some point :)

qw The Game (N950, N9 (+Symbian): Ovi Store, N900: .deb on request, @qwgame)
This game is similar to Qix, but has its own style, and the enemies are a bit different from Qix - but it basically is an area filling game. The reason why the game is called "qw" is because it started out as a small Python hack (qw.py) during the Super Gamedev Weekend 2010, and qw were the first two letters on my keyboard. A nicer explanation is that it can be spelt (in German) like Cuvée and a reference to the different blend of different photos (flowers, places, animals) that you have to play through. The photos have been done by vogelvau, the menu structure is done using QML and the gameplay itself uses a QGraphicsView-based drawing engine.

That Rabbit Game (N950, N9, N900 (+Symbian): Ovi Store, @thatrabbitgame)
This is my first game to be published in Ovi Store; it's a "inverse duck hunt"-style game where you control the flying rabbit head, and have to get yourself shot by approaching the crosshairs and keeping steady. Flapping the wings is done by touching (the strength depends on the duration of the touch) and moving left and right is done using the accelerometer. The initial version of this game was developed in Java as an Android game for an OpenGL ES course at our University (PDF). The game for Maemo, MeeGo and Symbian is a complete rewrite in C++/Qt with the artwork taken from the original game, which I did myself in Inkscape. There is also a webOS port using OpenGL ES.

Tennix (N900, N8x0: Extras)
This one is quite old, and is actually based on a really, really old codebase of a school project from 2003. In 2007, I decided to port it to SDL for Desktop Linux, Mac OS X and Windows, and since SDL is available on Maemo as well, I then ported it to Maemo 4 in January 2008. A special "2009 Edition" was created for the N900, with updated controls and a Python-based AI enemy (using the CPython API / libpython). What about Harmattan you ask? Well..

Some of these games are just free and closed source for now. I do, however, definitely plan to release them as open source in the future. The problem is having used non-free artwork in the early prototyping stages (i.e. getting "something" visible in the engine) before replacing them with my own artwork, so I'll have to make sure to remove these things from the repository history before publishing the source. Also, code cleanups need to be done ;)

Download and enjoy the games - I'd be grateful if you could leave some feedback (either via Ovi Store, Maemo Talk, comments here or e-mail).

gPodder QML Mock-ups by wazd, part 1

Andrew Zhilin has been creating awesome mock-ups for the last few months for gPodder's new QML UI. Back in December 2010, Andrew started with the first mock-ups based on the screenshots from meego.com:

After that, we decided to go a step further and make it look even more futuristic (this was partly inspired by Metro - two months before #feb11). Most of the title bar and podcast list design have been kept (although evolved) in the current design. This is also the first time that Andrew integrated the playback feature into the mock-ups - a player "widget" that can be pulled down. In the current version, it's still a widget that can be brought in with a tab, but it's placed on the bottom:

And here are two more of these rare mock-ups - the first one was a suggestion for the main menu (something which we don't have at the moment - the "main view" in gPodder/QML currently is the podcast list, with buttons in the title bar for more actions). The second one is also a very unique design in my opinion - I especially like the vertical progress bars, and the slick black-and-gray color tones. The gray rectangle at the top of the second mock-up was just a placeholder for the window manager's title bar:

Stay tuned for more mock-ups by your favorite Russian designer in the second part. Also, the real implementation of gPodder/QML is progressing nicely. Expect some additional updates on this in the next days, too :)

gPodder on the N900 MeeGo 1.2 Developer Edition

If you want to try the MeeGo N900 Developer Edition for the N900 but think that clicking through the Widgets Gallery gets boring after 45 minutes, why not try out the QML UI of gPodder on it? It's pretty easy. This post assumes that you are using the alpha release of the N900 Developer Edition from a microSD card and boot via USB.

Thankfully, Python 2.6 is already preinstalled, but you need recent PySide packages for gPodder to work (PySide exposes the Qt framework to the Python world), you can get them from PySide binaries for MeeGo. You don't need to upgrade Qt, simply installing the PySide packages is enough:

zypper addrepo http://download.meego.com/live/home:/renatofilho/Trunk/ pyside
zypper install python-pyside

What you need now is a recent Git checkout of gPodder's "tres" branch. I suggest you do that on your computer:

git clone git://repo.or.cz/gpodder.git
cd gpodder
git checkout tres

Now there are two pure Python dependencies for gPodder that you also need. As there are no packages for them in MeeGo yet, you also have to provide them manually. The first one is the Universal Feedparser. Grab a recent release from the downloads page and copy the file feedparser.py to the src/ folder in your gPodder checkout. The second dependency is mygpoclient, a client library for the gpodder.net web service. You can check out the latest version from Git:

git clone git://repo.or.cz/mygpoclient.git

In the checkout, you will find a folder called mygpoclient - copy this to src/ in your gPodder checkout. Now you have a complete, self-contained gPodder checkout on your computer. Use rsync or scp -r to copy it over to your N900 (you can use USB Networking for that).

Now that you have everything on your N900, you have to add some subscriptions manually (mostly because the QML doesn't yet have the UI required to subscribe to new feeds) - use bin/gpo to start the command-line utility, then do something like subscribe fb:linuxoutlaws to subscribe to an example podcast. Quit the command line application and start the QML UI using bin/gpodder --qml, which should - after some loading time - show gPodder/QML on your MeeGo 1.2 Developer Edition environment.

If you have made it this far, don't stop here - try out the examples from the PySide/QML Tutorial and familiarize yourself with Python development on MeeGo - it's easy and fun!

gPodder 2.15 available; QML UI plans and Diablo support

A new version of the open source podcatcher gPodder is now available for Maemo 4 (Diablo, N800 and N810) and Maemo 5 (Fremantle, N900). For Diablo, the package is already promoted to the Extras repository, so it should appear as an update soon, and for Fremantle, it's in Extras-Testing waiting for some reviews and votes from you (yes, you!). Please test and vote for gPodder 2.15-1 in Extras-Testing. This is a bugfix release in the stable 2.x release series, and also includes some translation updates as well. For full details, see the official release announcement.

Because I've been asked about the QML UI several times now: It's still not day-to-day usable, and missing some features. It's also only included in the "tres" branch, and won't be included in the 2.x release series. Judging from the current performance of QML UIs on Maemo 5, I also think that the Hildon-based Gtk+ UI might be better suited for Maemo 5, especially since it has been polished for the last 1.5 years - that's why the current Maemo 5 UI will most likely still be the default, even when gPodder 3 comes out (with the QML UI as an option).

Support for Diablo will be dropped in "tres", but as there haven't been any new features for Diablo in the last several months, that's not really a problem (bug fixes will still be made to the 2.x branch of gPodder, even after "tres" is released - you just have to report them).

That said, the QML UI will be available (and the default) for environments like the MeeGo N900 DE and probably any other MeeGo UIs (tablet, handset, etc..) in the future, and it will come with some exciting new features and a streamlined user interface.

gPodder/QML progress update

While the 2.x branch of gPodder is still updated - a new release should be out soon - the awesome stuff happens in the "tres" branch, where the refactoring takes place and also where the QML UI is built. I've reserved some time this weekend to work a bit on the QML UI so that it is at least day-to-day usable for me, because it turns out if I don't force myself to use the QML UI, I'll just use the Maemo 5 UI and not work on the QML UI ;)

I've uploaded two new videos today: gPodder/QML on the N900 and gPodder/QML on a Desktop. This is exactly the same Python codebase (utilizing PySide), which is great for testing on the "big" computer. It's also truly cross-platform, as you can see it running on OS X in the Desktop video. Unfortunately, Qt Mobility 1.2's QML Video component is broken, so there's no video playback on the N900. Video playback great on the Desktop, though, and audio playback works fine on both the N900 and Desktop.

The UI is still in a rough state, but it's a great place for experimenting around with some ideas to see what works and what does not. I really like the integration of the playback feature into gPodder, as it provides a better integrated experience on handsets. It obviously also loads faster compared to loading a separate media player. The UI is scalable and should work well on tablets (which is especially useful for YouTube channels and video podcasts).

The new codebase still hast the Desktop GTK+ UI and the Maemo 5 GTK+/Hildon UI in there, they share the same backend code as the QML UI. The code is not ready for public consumption, but if you really want to try it out, you'll find the code in the "tres" branch in our Git repository. If that's too little information for you to get started, then you shouldn't yet use it :)

gPodder 2.13 in Extras-Testing (and in Extras for Diablo)

A new version of gPodder, a podcast downloader for Maemo 4 and Maemo 5 has been released. The new release is already available in Extras for Maemo 4 (i.e. N800 and N810), and is currently in Extras-Testing for Maemo 5 (please test and vote!). You can read the official announcement on the gPodder blog, or go directly to the detailed ChangeLog. This release fixes some issues reported by our users, improves the episode list on Maemo 5 and adds the often-requested "Download only when on Wi-Fi" feature:

This release does not yet contain the QML UI, as it is not ready and/or feature-complete yet, and the QML development happens on another branch ("tres" in the Git repo) that contains more under-the-hood changes that cleans up the gPodder codebase. The QML UI will be released "when it's done" :)

gPodder/QML status (with screenshot and video)

Ohai February. The winter term is over; time for some gPodder QML hacking. This means that gPodder gets a new UI, and the structure of the application and the usual workflows also change a bit, based on the experiences with gPodder on Maemo 5. One of the most important changes will be that content will be played inside gPodder, as this provides even more control over playback and resuming than what the MAFW integration with the Maemo Media Player can provide.

Most of this has been done in the last two days. Thanks to Python, PySide and QML, I'm able to reuse the gPodder codebase (feed parsing, downloading, etc..) and just slap a lightweight QML UI on top of it.

Andrew Zhilin (aka wazd) has helped a lot with the design and the artwork, but see for yourself (this is a screenshot, not a mock-up):

And here is a video of the current performance on a N900:

Feedback, as always, welcome :)

Maemo App Development - One Year Ago

I just realized that one year ago, I was giving a talk about Maemo Development at the Metalab here in Vienna. Back in January 2010, things were still very much different from today:

• Scratchbox was the SDK - Linux only, VMs for everything else
• No proper IDEs for Hildon development (there was Eclipse integration, but I never used it)
• Qt still was "the new stuff that's coming up" for Maemo development
• Mer was still something to look forward to
• MeeGo didn't exist - Maemo 6 was the future ;)
• MADDE was in Technology Preview state - not widely used
• Direct UI (now MeeGo Touch) was thought to be the future toolkit
• Qt 4.6 was just released in December - no QML in Qt yet

It turns out that we are in a much better position now, we've got a nice cross-platform IDE (Qt Creator), a proper SDK (Qt SDK) that works on Windows and OS X the same as on Linux and the "low-level" issues (optification, packaging, ...) are handled by Qt Creator mostly.

Today, the issues are different - I'm complaining about Qt Creator (from the Qt SDK 1.1 Preview) crashing a lot in QML design mode, I can deploy my apps to Symbian devices without much effort (didn't think I would ever do that) - even though there's no proper toolchain for Linux or OS X (Remote Compiler doesn't count). The Qt Quick Components are still not released, even though I'd love to create some great apps with them. And most people forget in the N9 rumor jungle that we have still got the best Linux-based mobile OS (with Linux userland) that exists in an actual product that you can buy right now (that's Maemo 5 on the N900 if you didn't get that hint..). Just like Duke Nukem Forever, a MeeGo handset will be announced and released eventually - give it some time.

Back to the "Qt Creator shouldn't crash when editing QML" developer story: We're not there yet, but comparing the current state with the state one year ago, that's some progress right there! Looking forward to those bits falling into place in the upcoming months.

New tutorial: PySide/QML on MeeGo

In addition to my old PySide tutorials, there is now a proper PDF guide for PySide development on MeeGo available. Except for packaging, all steps apply to Maemo as well, and this is the document that includes the first gPodder QML UI code example (the final gPodder QML UI will be totally different and "much cooler", though).

As part of the new year's cleanup, I also dug out the old MTF UI demo of gPodder and put its source online here - for third party applications, QML is now the preferred UI over MeeGo Touch, so this might not be of much use for you now, but maybe somebody can put it to good use.

The Qt promise and what Maemo 5 needs

(tl;dr: Nokia should provide updated Qt packages as official SSU for Maemo 5.) Before I start, here are some facts (correct me if I'm wrong):

• The N900 runs the Maemo 5 operating system
• Maemo 5 received some updates (the latest one being PR1.3)
• We don't really expect PR1.4 to come out any time soon, if at all
• The MeeGo Handset images from meego.com are inferior to Maemo 5 and not a replacement (and never will be)
• The MeeGo operating system on the first Nokia MeeGo handset will have a proprietary UX and proprietary apps, and won't be available for the N900

In summary, it means: We are stuck with Maemo 5 on the N900. And that is a good thing! Lots of useful apps, a helpful community (if you subtract the trolls) and a polished OS. Sure, there's room for improvement, and lots of open bugs that should be fixed, but that's another issue (which will ideally be solved by open sourcing closed components with bugs that Nokia isn't interested in fixing anymore and by the Community SSU). This one is about Qt.

Two days ago, an e-mail was sent to maemo-community, proposing a "community service pack", which basically is a big pile of workarounds. Read my response for some initial thoughts.

When Qt arrived on Maemo 5, the promise was two-fold:

• Write your apps in Qt and you're ready for MeeGo (apps written now will run on the platform released in the future)
• Maemo 5 gets Qt support, so MeeGo apps will run on the N900 (apps written in the future will run on the platform released now)

It turns out that the first one will probably hold true (surely with QML, maybe even with QWidget), while the second one is doubtful, as Maemo 5 has only got Qt 4.7.0 through the official channels (PR1.3), with no real official update in sight. If you use QML, use QtQuickCompat as workaround ("Qt Qml plugin that reregisters all “Qt 4.7” types in the “QtQuick 1.0” namespace … useful if you’re forced to stay with 4.7.0 (e.g. on N900), but still want to use the new namespace.").

There is also a real bug (yes, a bug!) in Qt 4.7.0 on the N900, and the fix isn't released as update - it's a new package: libqt4-bearer-hotfix ("This is a hotfix for the broken ICD package in Qt 4.7.0. It can be removed once Qt mobility 1.1 is released."). Now, the proposed "Community service pack" would combine all these fixes into a single dependendable metapackage (yes, a new one). It becomes the "Unbreak my Qt" feature that every app developer has to depend on and specify in the packaging.

This is wrong! No developer targetting MeeGo who has not heard about Maemo 5 will go through all those ugly workarounds and spend a week fixing things up for Maemo 5 just so that the app works. Now imagine what would happen if the first MeeGo device also introduces such kludges once it falls out of its support life cycle. Or what if the problems on Symbian are similar, and developers have to special-case things there. Not only for Symbian^3, but also for S60v5? Fragmentation.

How to avoid fragmentation? Simple: Provide Qt as a "feature" with a quicker release cycle that can be updated every month if need be. Provide Qt updates also for operating systems that don't get updates for the OS anymore. Here's my proposal:

• Provide SSU updates for Maemo 5 for Qt (and Qt Mobility) through official channels (that's the important part here!)
• A new Qt (and Qt Mobility) release should be available on all platforms (Maemo 5, S60v5, Symbian^3, MeeGo) at the same time through official (end-user approved) channels
• Apps targetting stores and repositories (Maemo Extras, Ovi Store, MeeGo Apps/Downloads) should be able to depend on the latest Qt (and Qt Mobility) version

Without that, you'll get fragmentation similar to Android: The 1.5, 1.6, 2.1 versions are similar to Qt 4.6, Qt 4.7.0 and Qt 4.7.1 (for example). Again, you don't need to update the OS, just update the framework - through official channels!

PySide/QML tutorials online, workshop next Sunday

To get myself accustomed to PySide UI development using Qt Quick (aka QML) and to check out what works already and what does not, I've experimented with creating some common elements that I'd use in an application (i.e. a QML version of gPodder - a blingy demo already exists) and decided to share my experiences and results as tutorials.

Here are all the tutorials in their current state:

• Selectable list of Python objects in QML
• Multi-selection lists in Python with QML
• Defining and using constants from PySide in QML
• Using QtWebKit and QML with PySide
• Updating QML content from Python threads
• Utilizing Qt Quick Colibri in PySide
• Filling and reading QML UI forms from Python
• Auto-generating QObject from template in PySide
• Using QtMobility sensors and QML from PySide

Screenshots are available on Flickr:

I'd like to get some feedback on whether or not the tutorials worked for you and were helpful and what else you would like to see. You can try out all the examples on your N900 today! Just install python-pyside and python-qtmobility (for the last example) from Extras-Devel and copy the examples from the Wiki. The usual disclaimers for software in Extras-Devel apply.

In related news, there will be a PySide/QML workshop at the December meeting of the Python User Group Austria, so if you happen to be in or around Vienna on Sunday, 2010-12-12, stop by at the Metalab and meet fellow Pythonistas.

Hildon UI elements in QML

I've been playing with PySide and QML this week (more on that soon), but here's something that might be interesting to the Maemo community: Using the native Hildon look and feel of Maemo 5 in QML.

This QML demo uses the current theme graphics of Hildon and provides QML components that can be used just like their Hildon counterparts, but inside QML UIs. This is not a complete library, just a test of what could be possible in case anyone wants to step up and create and maintain a Hildon library of QML components. Here's a video:

The code for this demo is on Github - you can try it out on your N900 using qmlviewer.

Maemo 5 app UIs: {The,A} big picture

Sooner or later it will be necessary to create a QML UI for gPodder if it is to integrate nicely with devices on which Qt is the "native" toolkit for third party apps. At the moment, the reusable UI elements that can be used with QML (Qt Components) have not yet been officially released (the Git repository is available on Gitorious, though), and there are no UI style guidelines for Harmattan out (yet?). I'm also not able to locate UI style guidelines for QML apps on Symbian^3, and there are only a few small sample QML apps out right now.

Let's look at what we have on Maemo 5 right now. Here's a simplified overview of the current Maemo 5 UI of gPodder:

You can also check out the full-size image (~ 3.5 MB).

The UI follows the Maemo 5 Style Guide where it makes sense and tries to come up with better solutions where the Style Guide does not have a definitive answer. I'd like to hear your opinion about the current UX of gPodder and how these concepts can be translated into a QML app that integrates nicely with "future" UIs (Harmattan, S^3). The new-style episode list that can be seen in this picture will be made available with the next release that will be out Really Soon Now™.

MeeGoConf 2010: Fun, QML, gPodder, Python

I've attended the MeeGo Conference 2010 in Dublin this week. Meeting people, playing werewolf or table tennis and discussing MeeGo Python are just some of the great things about this conference.

One of my burning questions for third-party app development ("QWidget? MeeGo Touch? QML? Which one of those?") was answered with "QML". I've played with QML before, and it's great, but right now, one has to work on a very low level (as in "design your own buttons") and without any UI style guidelines. Let's hope the Qt Components provide reusable UI parts there and that the style guidelines are published as soon as possible.

I've also got some gPodder feedback: Niels suggested subscription pausing and auto-deletion of episodes (both are already implemented and just need exposure as UI elements). Murray suggested a custom TreeModel implementation for the episode list, which I've started working on now. Mike suggested the often-requested multi-episode deletion feature, which is also something I plan for the next release.

On Wednesday, we had a Python BoF to discuss the state and future of MeeGo Python. I'm looking forward to using PySide for the QML UI of gPodder. A PySide/QML workshop is planned for the next PyUGAT meeting, so join in if you are in Vienna in early December.

Oh, and the IdeaPad that we got from Intel is great. Thanks a lot for that. Will come in handy for prototyping and testing Touch UI interfaces!

Hope to see you again in a future MeeGo event :)