09 March 2010

The joys of Python and Qt

I'm currently working on a tutorial regarding MeeGo, the new Linux-based embedded platform born by the merging of (Nokia-sponsored) Maemo and (Intel-adopted) Moblin. MeeGo is probably the closest thing we'll ever get to a real "Linux for the masses": differently from Android, where Linux is just a kernel for Java to run on top, here we'll have the full GNU toolchain, X display, desktop technologies based on FreeDesktop standards, RPM packages, etc etc.

The main development toolkit for MeeGo, from now on, will officially be QT. This seems to fly in the face of reason, having two existing GTK-based codebases from both "parent" systems which have already been deployed on production devices, but it's actually a very smart choice, as I was reminded just today.

This morning, I was working on a laptop running Windows XP. I built a couple of forms with Qt Designer, then fired up my trusty IDE and wrote the main code, about 150 lines of Python that will download some files, manage a few controls and then display a web page.

After completing a full set of tests on the local machine, I copied it to my (Maemo) phone, and again it was working perfectly -- without any change, recompilation, deployment, anything. Then I went home and copied it back to a different laptop running Kubuntu Linux, and again it was running just fine. Had I had a Mac (or iPad?) laying around, I'm confident it would have run there as well without any change. Consider that the version of QT and PyQt was slightly different on all machines, just to give it a further twist.

Obviously this level of portability has a price. I had to write my code using constructs like QSettings and QNetworkAccessManager rather than messing directly with the Windows Registry or HTTP_PROXY variables. I have yet another (leaky) abstraction layer on top of the OS, which may or may not be to everyone's taste, and the program runs in a sandboxed runtime, which might be slower than natively-compiled code (although this is debatable, these days); but I didn't have to write three different codepaths for each and every interoperation with the OS. I didn't have to worry about having a $HOME or a %HOME%. If I have to worry about packaging is just because I have to write about the ins and outs of a particular platform; in other circumstances I could have simply relied on python tools to do the right thing.

Python and QT could finally deliver the dream of portability that Java promised, if only we give them a sporting chance.

03 March 2010

CallBlocker for Maemo

Last week, Vinu Thomas came up with an ingenious script that will silently drop calls on your N900 if they come from a list of "blocked" callers. I never thought you could do that, but apparently there have been quite a few apps for this sort of things on more established platforms like Symbian and iPhone.

At first I suggested a few minor improvements to the script, then I thought I might as well repackage it in a proper application with a proper GUI. I asked permission to Vinu (something the author of "pycallblocker" didn't bother to do), and then I went ahead and put it on Garage.

So there you have it: CallBlocker 1.0 for Maemo 5. Note that it relies on the python2.5-qt4-gui package, currently available only in the extras-testing repository.

The current feature-set is quite limited: you basically enter a list of phone numbers, and callers (exactly) matching them will be sent a busy signal or redirected to voicemail.

It did get quite a warm reception on talk.maemo.org, so I'm motivated to keep development ongoing (at the expense of other, still-unreleased stuff I have almost ready). The current plan is to release a 1.1 version with support for suffix wildcards (e.g. entering +441234*, all numbers beginning with +441234 would be matched and dropped) and better daemon management. Then, time permitting, I'd like to have a 2.0 with features like blocking all withheld/private numbers, blocking SMS texts, blocking specific contacts from address book, blocking all numbers not in addressbook, blocking only during some hours, and possibly even a "whitelist" mode.

Once it reaches a certain maturity, I'll probably consider moving it to the Ovi Store, at which point PyQt licensing issues might arise, but we'll cross that bridge when we get to it.