N950 Arrival and My Development Plans

A couple of weeks ago I was notified by Quim Gil that I was selected for the MeeGo Community Developer Device Program for a Nokia N950 devkit.  Prior to this I had been quiet in Maemo-land for a little bit while I worked on an experimental rewrite of one of my applications that uses PyGame.  Seeing as PyGame isn't on the N950 I hurried up in getting it to a state I could put aside and moved on to learning QML.

The excitement increased as I saw the box personalized with my name regardless of that personalization just being a piece of tape

MeeGo Development

My development plans have changed (and frustration increased) over time as the MeeGo development story has gotten refined.  This is due to both changes in the UI toolkit availability and rules for distribution of applications.

Originally when things shifted to Qt I chose QWidget because it was ready now, includes widgets, and was recommended by Nokia (you know, the people who own Qt) for the types of apps I write (which recommendation was removed on June 22, 2011).  At MeeGo Conference I found out that some (most? all?) MeeGo instances are not including QWdget themes (which without a theme its basically dead).  QWidget in Qt5 will be optional and will probably not be included on those same MeeGo instances that currently don't ship a theme.  So there goes that work.

I am still a bit frustrated with QML in that there is not even a subset of common QML Components between platforms though some disagree on it being a problem.  I've just seen really terrible QML applications which mostly stem from everyone reinventing the same bugs when writing widgets from scratch.  I also find it a wonderful experience having the widgets available for the desktop such that I can write apps in a desktop environment that are targeted for small screens without the need for any pesky IDEs and emulation.  When it comes to testing, I am much more efficient testing and debugging natively on the desktop and just need to spot check how it translates to my devices.

I do not look forward to packaging for generic MeeGo.  I found out at MeeGo conference that dependency management isn't guaranteed to be included and one has to include in their package any dependencies outside of core MeeGo.  This is fine for compiled applications, you just pull in static libs.  This is not as simple for Python developers where part of the beauty is your program isn't compiled and any compiled extensions are distributed and maintained separately.  I have contemplated some tools to simplify this (based on cx-freeze and Hatchet) but that is a good amount of work and focused away from what makes all of this fun.

At MeeGo conference I raised my concern for packaging Python applications during the apps.meego.com lunch time BoF.  The impression I got then (no clue if things have changed) is that they will focus on MeeGo compliant apps at first and might later support others.  Even with that concession this is a stark contrast to the original vision that helped bring me on board from Maemo about (what was then called) Surrounds which would serve both as an app repo and as a place for third-party dependencies.  If I chose to not bundle all of my libraries then I also am not available for any of the other distribution channels (and any contests they might be running).  I don't program for the reward of the contests but it isn't fun feeling excluded.

The beauty of developing for Maemo was it had very low friction in the development story thanks to Python that I was able to spend more time focusing on what was fun: designing software for end-users to enjoy.  I feel that this is being lost in MeeGo.

MeeGo and Nokia

The picture can be better when focusing on a individual vendors.  Vendors may keep things a bit more lax with their distribution channels.  The problem is then you are customizing per vendor which requires device availability for testing and a lot more work.  That vendor has to be worth it.

Nokia is worth it (even without the DDP).  Nokia actually shipped a great device previously (N900 running Maemo5) and is committed to shipping the N9.  That is a lot more than other vendors can say.  On top of that Nokia offers a great experience with the software and hardware.  So as a user, Nokia is worth it.  What about as a developer?  Nokia has Qt Quick Components to provide reusable QML widgets.  They also will support dependencies and have Python/PySide available in their store.

The Way Forward

For my initial ports I will continue to focus on what keeps this fun, writing apps for end-users despite any downsides of being vendor specific.  After that I will bite the bullet of making my applications MeeGo compliant to make them available for a wider audience.

The default date.  It's good to see somebody at Nokia has a sense of humor

I have work to do on all of my applications but I will be focus on the ones that still use GTK first, especially since they are fairly simple.   I am using QuickNote as my playground for learning QML.  Expect further posts regarding progress updates and lessons learned regarding QML and MeeGo 1.2 Haramattan.