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!

This weekend's releases: Tap Tap N950, qw.py and the IP Address Widget

Over the weekend, I've pushed out some code for your enjoyment: First up is the incomplete but maybe interesting QML source code of the Tap Tap N950 prototype. I probably won't find time to work on this, but it would be sad to let the small piece of code rot - maybe someone wants to pick up the development of it. I'll answer any questions related to the code in the thread :)

Next up is the open source release of the qw prototype "qw.py", which has been developed during the Super GameDev Weekend 2010 at the Metalab Vienna last December (the next one is at the upcoming weekend; stop by if you are in Vienna!) - nearly 1 year ago. This is not the same as qw The Game in Ovi Store, but it's an earlier version, which still contains multi-player support (4 players on one PC keyboard), and it's written in Python, so it should be easily hackable.

And last but maybe not least is the IP Address "Widget" for Harmattan. This small hack (which is inspired by the earlier Calenderr calendar icon hack) makes use of the fact that the Harmattan UX reloads the icon of an application whenever the .desktop file or the icon file itself changes. The details (and a .deb for easy installation) can be found on the website - basically it shows a way to have semi-interactive "widgets" on the app list on Harmattan. I'm sure that creative readers can come up with some cool ideas :)

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

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!

Fast MeeGo Handset UX on a N900 (Video)

I've had the chance to play around a bit more with the MeeGo Handset UX on the N900 yesterday (1.1.80.0.20101001.1). Carsten provided experimental graphics drivers, which still crash at a few points, but for the first time provide acceptable performance in the UI. I also decided to build the gPodder MeeGo Touch Prototype UI against libmeegotouch. Unfortunately, there's no SDK yet, so I had to use zypper on the device (via SSH) to install libmeegotouch-devel, make and gcc-c++ and then take a long coffee break after entering qmake ; make. As it's using plain Qt, the TRG binary built from the Fremantle SDK worked fine on the device.

If you don't see the embedded video, click here: MeeGo Handset UX on a N900 (w/ TRG, gPodder UI test, HW-accelerated).

Qt: Write once, #ifdef everywhere?

Despite what the title of this post might suggest, I really like Qt. But as a developer, I also know that "write once, run everywhere" isn't realistic without writing some special-cased platform-specific code. Qt does take care of many platform-specific things, and I think it's the closest you can get to "write once, run everywhere" right now.

This post should serve two purposes: To provide a real-world example of what needs to be done in the code for the app to work on both Maemo 5 and Symbian^3 (with example code), and to get suggestions on what parts I could rewrite in a more platform-agnostic manner with existing APIs (so please comment if you are in the know!).

Here's the story: In early September, I've rewritten my game "That Rabbit Game" to use QGraphicsView on the N900, and in the last weeks, I've ported it to Symbian^3. I use the macro Q_OS_SYMBIAN to check for Symbian and Q_WS_MAEMO_5 to check for Fremantle. Here's the current main menu on a N900 and N8 (different screen resolutions and aspect ratios):

Qt modules: In the qmake project file, I can use linux-g++-maemo5 to add Maemo-specific configuration, and symbian for Symbian-specific settings. I use D-Bus module on Maemo, but obviously not on Symbian, so my project file contains something like this:

linux-g++-maemo5 {
    QT += dbus
}

This is nice, because I only have to maintain one project file, and the block structure is very readable (and I can even use different Qt submodules for each platform).

Screen orientation: Symbian has auto-rotation for Qt apps by default, and Maemo 5 has landscape-only mode by default. For my game, portrait mode does not make sense, so I have to request landscape-only on Symbian (similarly, if I want auto-rotation everywhere, I have to request it on Maemo 5 and do nothing in Symbian). For this specific case, I need some libs in Symbian, so I add this to the project file:

symbian {
    LIBS += -lcone -leikcore -lavkon
}

I also need to add this to the top of my main source file:

#ifdef Q_OS_SYMBIAN
#include <AknAppUi.h>
#endif

And finally, I have to copy'n'paste a code block into my main() function before I create the first window:

#ifdef Q_OS_SYMBIAN
CAknAppUi* appUi = dynamic_cast<CAknAppUi*> (CEikonEnv::Static()->AppUi());
TRAPD(error,
if (appUi) {
    // Lock application orientation into landscape
    appUi->SetOrientationL(CAknAppUi::EAppUiOrientationLandscape);
}
);
#endif

It would be nice if Qt (or Qt Mobility?) has some generic API for this, where I just need to do something along the lines of QRotation::setMode(QRotation::LandscapeOnly); and let it take care of the platform-specific stuff.

Accelerated QGraphicsView: On Symbian^3, QGraphicsView is automatically accelerated via OpenVG (I think), but on Maemo 5, it can use OpenGL for this (but does not by default), so in the code where I create my QGraphicsView, I have to have this at the top:

#ifdef Q_WS_MAEMO_5
#   include <QGLWidget>
#endif

And then somewhere down that file where I create the QGraphicsView, this code goes there:

#ifdef Q_WS_MAEMO_5
    QGLWidget *glw = new QGLWidget(QGLFormat(QGL::DoubleBuffer));
    view->setViewport(glw);
#endif

It's not that difficult, and is already cross-platform (on platforms where OpenGL is available), but maybe QGraphicsView can be OpenGL-accelerated on Maemo 5 by default. Maybe there is some non-obvious side effect that using an OpenGL viewport has that I'm not aware of, and that's why one has to do it manually.

Accelerometer readings: This might actually be a bug in Qt Mobility. For my game, I have to read the accelerometer's Y axis on Symbian, and its X axis on Maemo to determine the rotation for the same holding position of the device, so there's another platform-specific #ifdef there. Again, this will hopefully be fixed in a future release of Qt Mobility, and will most likely be fixed for MeeGo as well.

Task switcher: It's customary on Maemo to have a task switcher button in the upper left corner. There's no platform-agnostic way of going to the task switcher, so I needed to special-case it for Maemo 5, and have not bothered implementing it on Symbian^3 (suggestions welcome!). First, I need to include D-Bus headers for this (I've already mentioned how to request the D-Bus module in the qmake project file above) :

#if defined(Q_WS_MAEMO_5)
#   include <QDBusConnection>
#   include <QDBusMessage>
#endif

When I'm in the handler code where I need to do the actual task switching, I can utilize it to activate Maemo 5's task switcher:

#if defined(Q_WS_MAEMO_5)
        QDBusConnection c = QDBusConnection::sessionBus();
        QDBusMessage m = QDBusMessage::createSignal("/", "com.nokia.hildon_desktop", "exit_app_view");
        c.send(m);
#endif

This is very much Maemo 5-specific, and will very likely not work on MeeGo Harmattan. Again, here it would be nice to have a cross-platform way of doing window management (in Qt or Qt Mobility?). I can imagine this being useful not only on handsets, but also on netbooks and tablets (from a MeeGo PoV). Again, trying to come up with pseudo-APIs here, QWindowManager::showTaskSwitcher(); could be a nice way to handle this in a cross-platform way, hiding platform-specific implementations. From what I've seen of MeeGo Touch, activating the task switcher there simply iconifies the window on the Desktop, so maybe if I would iconify my main window, it should activate the task switcher on Maemo 5 and Symbian. It does not work on Maemo 5 right now, though, and I haven't tested it on Symbian.

Screen resolution: This was (thanks to QGraphicsView) less of a problem than I thought it would be. Symbian^3 (or at least the N8) uses 640x360 as its resolution, and Maemo 5 uses 800x480. Maybe the MeeGo Harmattan device will use yet another resolution. I still configure my QGraphicsScene object manually via #ifdefs to get a good resolution, but the code could just measure the resolution and configure the scene as well. Here's what I use:

#if defined(Q_WS_MAEMO_5)
    setSceneRect(0, 0, 800, 480);
#elif defined(Q_OS_SYMBIAN)
    setSceneRect(0, 0, 640, 360);
#endif

I then use the sceneRect() of my scene to calculate a scale factor for all contents and call setScale() on all root items of the scene to scale the contents to the current screen size. You might have to take care of different aspect ratios on different devices, too - but it was unproblematic for my use case (the game) this time.

gPodder running in the MeeGo Handset UX for N900

Three days ago, a new MeeGo Handset UX image has been released for the N900. I wanted to try out gPodder on it to see how far I could come without any coding...

It was quite easy to get things going: Download the image, dd it to a MicroSD card, boot the kernel (detailed instructions) and set up USB networking. After that, I could ssh into the environment (the root password is meego) and have a look around.

Instead of using apt-cache and apt-get to search for and install packages, I utilized yum to search for and install PyGTK. Then, I used rsync to copy my Git checkout of gPodder to the device. There are two additional dependencies for gPodder that aren't yet available in the MeeGo repositories, namely feedparser and mygpoclient, so I just copied the Python modules from my Laptop into the src/ folder of the gPodder checkout. Then, just switch to the MeeGo user (su - meego), make sure that the DISPLAY variable is set (export DISPLAY=:0) and start gPodder from the source folder (with bin/gpodder - it automatically loads the modules from the right path) - gPodder says hello MeeGo.

The basic functions work, it's just that the Desktop UI isn't suited for mobile devices (the MeeGo compositor/decorator also has several problems, but that seems to be a more general problem). Python bindings for Hildon aren't (yet ?) available, so I could not test the Maemo 4 or Maemo 5 UIs, but I would like to do a proper Qt/MeeGo Touch-based UI for gPodder, anyway. Let's hope the PyMaemo or PySide teams are quick to release bindings and make them available in the MeeGo repositories, so Python developers can create usable UIs for MeeGo handsets :) Oh, and two MeeGo-Python facts: It comes pre-installed in the N900 image, and the version shipped is 2.6.

In short: Apart from the UI framework, everything is already in place (and working) for Python on MeeGo. With the recent release of Qt Mobility for PySide, let's hope that MeeGo Touch bindings are not that far away.

SketchyAetch, gPodder/Qt and living in the present

After the very interesting Nokia Mobile Developers Forum in Hagenberg on Friday and Saturday (Petri Niemi did several interesting Qt introductory talks), I decided to play a bit with QGraphicsView again and this time try to come up with an app that actually does something: SketchyAetch!

Having not done much with C++ for several months, the GCC error messages (at least for C++) are still kind of cryptic. The fact that code gets pre-processed by moc does not help here, as the error messages might appear in a different location than where the real error/typo is. It should not be too difficult to get around these issues after some practice, and from that point on, getting things done (in C++) with the Qt libraries should be nice.

Already-drawn lines will fade away when you shake your device just like you would expect. The package is available in Extras-Devel.

Now something for the Qt fanboys out there: If you're running gPodder 2.3 on your device, you can try

   python -m gpodder.qtui

for a PoC "yes we could use Qt for the UI layer". This is not something that we will be working on in the near future (after all, the Hildon-based Maemo 5 UI is perfectly fine and "native" and it will get some more fine-tuning with the next release), but it shows that it won't be too difficult to do a DirectUI GUI for gPodder on top of the existing podcast client for M6/MG. We probably get around to implementing a DirectUI GUI for gPodder later this year when it's time to think about "Maemo 6" support.

Looking back how strange the gPodder Fremantle UI looked back in June 2009 (and how much changed in both the Framework and gPodder until the first Fremantle version was released), there's no rush in switching to Qt or DirectUI (at least for existing applications). I just hope that good Python bindings will be available for DirectUI/Qt when it's time to support the new UI, but I'm sure the PyMaemo team will do a great job just as they did with Hildon/Fremantle.

Maemo 5 is very polished these days, and I expect it to be even more mature when PR1.2 is out. It's also nice to see the Qt bits fall in place, DirectUI widget demos being made available, and MADDE becoming integrated with QtCreator, so the tooling support is ready when it's time to write M6/MeeGo apps. Maemo 6/MeeGo is for later this year, now it's time to enjoy Maemo 5, the N900 and all the great open source apps :)