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!

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

Nokia MeeGo phones Nokia N10 & Nokia E5x

MeeGo has been created by Nokia and Intel together to begin a shining new era in mobile computing.They created MeeGo, a Linux-based open software platform with a vision that all kinds of hardware devices viz. Mobile computers, PC tablets, media-based phones, Tvs and infotainment systems of vehicle. MeeGo is an open platform and can be used in new Nokia phones. Nokia N10 and Nokia E5x are those mobile phone which will launch in later 2010 or 2011 with Meego operating system.Thus, applications developed for this OS would easily sell Nokia’s Ovi Store.

The Nokia N10 detailed specifications and features are not known but we know that this glorious new phone would have huge display screen and will also sport a 12MP camera (just as Nokia N8) but with quad-LED-flash (not Xenon Flash). It makes its photo snapper night video shooter.

The quality of videos and photos can be viewed in high quality HDMI. The handset would look dashing with its 4-row tilt hinge QWERTY keypad. Nokia E5x ran on Symbian but Nokia E5x runs on MeeGo and is a Dream Nokia Phone. Its Touch & Type context is certainly innovative and cool.

Modifying the Maemo 5 task switcher and launcher

This will be the last post for this week, I promise ;) After playing around with the MeeGo Handset launcher and task switcher, I decided to have a look at how this could be implemented in Fremantle, because the big previews and the paginated launcher are easier to use in some cases (you can also checkout the contents of a window while scrolling by without having to activate it). hildon-desktop manages the task switcher and launcher, among other things. The results of two days of hacking are two patches:

• Single- and double-column task switcher and the
• Paginated launcher icon grid

What I'm missing right now and did not succeed in implementing straight away is the "snapping" of TidyFingerScroll to page boundaries, so that whenever a scroll operation is finished, it automatically scrolls to center the icon page (for the launcher) or a preview window (for the task switcher). Obligatory demo video (.debs and patches are linked from the threads above if you want to try it out yourself) here:

If you happen to have experience in Clutter, why not give it a try? I suppose you would just need to implement another scroll mode in TidyFingerScroll and then request this mode in hd-task-navigator.c and hd-launcher-page.c. Who's up for the challenge? :)

Random observation: Hidden in hd-task-navigator.c one can find a geeky gem:

  xthumb = ythumb = 0xB002E;

A new gPodder release should be ready next week. And now back to some Uni stuff :)

Playing around with MeeGo Touch

While the MeeGo Touch Python Bindings are still not packaged and released, I though I'd give the C++ library a try and have a look through the class hierarchy. After getting the basic "Hello World" app running, I decided to create an application that can load the list of subscriptions from gPodder's SQLite database:

This view uses MContentItem, which already provides an icon and two lines of text - correctly styled and ready to go. Menu and toolbar items are MAction objects that can either appear everywhere or only at specific places (e.g. only in the toolbar). The great thing is that this all works on your Desktop in a normal window, so testing applications on your computer will be much easier with MeeGo Touch than it is with Hildon (which does not really run without its own hildon-desktop session in Xephyr).

The screenshot above is from the prototype written in C++, and shows how a gPodder MeeGo UI could look like. The MeeGo Touch UI of gPodder will be implemented in Python once the bindings are ready - the framework seems to be fun to work with so far. If you would like to play around with it yourself: MeeGo Touch is available from the MeeGo PPA of Ville M. Vainio if you are on Ubuntu and don't want to build it yourself.

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.

headphoned 1.9 for the N900 is now in Extras-Testing

The beloved Headphone Daemon, who usually sleeps in the darker corners of your N900 and makes sure that you do not embarrass yourself in front of other passengers or pedestrians with whatever kind of experimental music you happen to listen to when the headphones are accidentally unplugged (also known as public transport situations) got a small facelift (also known as code change).

A few changes that have accumulated over the last few months have now been packed up into the shiny new 1.9 release:

• Support for libplayback / whitelisting (by Faheem Pervez)
• Support for pausing Martin Grimme's MediaBox
• Detect headphoned disconnect during active calls and send pause command after the hangup

The last one in this list might be of special interest to some of you who have complained about headphoned not working when the headphones are unplugged during a call. This won't happen now, as headphoned now monitors the call status via D-Bus and keeps track of active calls. When the headphones are unplugged while a call is active, the pause signal will not only be sent right away, but also a second time when the call gets disconnected. This work for all types of voice calls, and should work for video calls as well (untested).

During the summer holidays, I have had less time to do more development and releases, but things are starting to move slowly again - expect new releases of packages like gPodder and MaePad in the upcoming weeks. I'd also love to port gPodder to Harmattan and add a fancy new MeeGo Touch UI on top of it (in March I said that Maemo 6/MeeGo is for later this year - which might be very soon now), so you can all enjoy your favourite podcatcher with the usual native UI support. Let's hope that the Harmattan SDK and/or Harmattan developer images get released for the N900 soon (and then the Python bindings soon afterwards - the PyMaemo team was very fast in previous release cycles), so the community developers have enough time preparing their apps for the next big release.

For now, please test and enjoy this new headphoned release, and don't forget to vote for and comment on the package once you have verified the new release from Extras-Testing.

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

MeeGo wishlist

Because all the cool kids blog about it these days..

• Follow the FHS (get rid of workarounds such as Optification)
• Remove Maemoisms and Scratchboxisms
• Follow freedesktop.org specifications (at least bugs 657, 1303, 3817, 3818, 3828, 3822, 3913, and 4766 according to this wiki page)
• Allow many different UI toolkits and languages (it's OK if you decide to provide official support for only a few of them)
• Make sure other UI toolkits integrate nicely (mostly covered by following wm-spec, icon-naming-spec and systemtray-spec and not inventing "MeeGo"-specific technologies and non-standard implementations)
• Make sure notifications work from other toolkits (libnotify-based vs. Qt-only notification widgets)
• In general, follow the ideas from the Mainstream Linux Aligment wiki page (the page is broken atm, but you'll be able to see the bug IDs)

If any of these specifications/standards do not meet the requirements, please work with freedesktop.org or other related institutions to get your extensions discussed, fixed and then integrated into the relevant specifications.

People will still develop mobile UIs specifically for whatever device will come along in the future, but porting from/to "mainstream" Desktop Linux should be as easy as possible.

There's a lot of awesome open source Linux/UNIX (GUI) software out there, it just needs some UI love to be usable on mobile devices. Don't make it harder than it should be.

(And with that I mean that it's easier to relayout a GTK+, FLTK, wxWidgets, Swing or Tk UI than to port everything to "the one true toolkit".)

This is especially true since open source developers usually develop in their free time, and porting an app to a new toolkit/environment is something that can't be done in two afternoons. Relayouting UIs can be done in that time.

Adding paradigm-shifting cool new UIs will still work without breaking backwards-compatibility and without restricting developers to one language/toolkit.

Oh, and Mer solves most of these issues by basing itself on a "standard" Desktop distro and only changing stuff that's really necessary.