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.
posted by GiacomoL @ 8:30 PM 0 comments links to this post
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.
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.
posted by GiacomoL @ 3:25 PM 0 comments links to this post
21 February 2010
KDE 4.4.0 on Kubuntu Karmic 9.10 -- a note of warning
I just upgraded my Kubuntu 9.10 "Karmic Koala" from KDE 4.3.4 to 4.4.0 using the backports repository. A note of warning: take a backup.
It took me something like 4 or 5 runs of
apt-get dist-upgrade /
apt-get -f install to get back a working setup. APT complained about a couple of things (python-qt3-doc conflicting with some newer package which includes the same examples, and Bilbo having been renamed Blogilo) but eventually pulled it through.
I was smart enough to backup the .kde home directory before launching a 4.4 session, and I'm glad I was. First run: Plasma crashed hard on a segfault, and didn't restart. Ok, this happened with some past upgrade already, let's just move away the old .kde home... got back a default desktop. Playing around with widgets, I hit another crash. And another. The culprit was always the Plasma Desktop, actual applications were running fine. Eventually, I moved back the old .kde home except the plasma* files under .kde/share/config/. This gave me back all my old KDE settings, except for Plasma. Win, I thought, and merrily set out to recreate my previous desktop arrangement.
So uhm. I'll try to track down what exactly Plasma doesn't like in my setup (which was, for the record, with two panels on left and right edge; Lancelot and a couple of QuickAccess widgets on the left, task manager and shutdown button on the right; two Plasma "views" and 4 virtual desktops), but if you are planning a similar upgrade, make sure you put aside some time for it, and get a good backup beforehand.
(I guess the question now would be "is it worth it?". Well, KDE does look more polished, applications are faster to launch and more responsive... it does look like we're finally at the point where one could upgrade from a 3.5.x release to 4.x and feel a bit awestruck.)
posted by GiacomoL @ 11:56 PM 0 comments links to this post
09 February 2010
The two presenter were a bit underwhelming (understandable after they went through the usual, hellish experience with British railway services), and there was little talk of my beloved Maemo, but it's hard to dismiss the technology stack they have chosen to go forward. Key element seems to be the QT library they acquired last year, which I know and love through the original Python bindings. It's powerful and as cross-platform as it can be, with a lot of mindshare in the Linux and Windows communities; this said, it's still C++, and it's hard to get excited about C++ these days. Also, the runtime will gradually appear on new and recent phones but probably won't make it to older ones.
One other thing I noticed was the presenters' style, typically European: self-deprecation and brutal honesty about things that work and ones that don't. It was refreshing, after weeks of Yanks propaganda from Google and Apple pushing their new gadgets as "fantastic", "amazing", "revolutionary" etc etc etc...
posted by GiacomoL @ 8:16 AM 0 comments links to this post
29 January 2010
Thanks to the lovely gPodder on my Nokia N900, I've recently discovered the net@night podcast by Leo Laporte. Like many regular podcasts, it's mostly full of random chatting and showmanship. In this respect, "new media" tend to be exactly like "old media": forced by their own schedule to blabber for the sake of it. But I digress.
The best segment of Laporte's show is usually an interview with someone from a startup, which is a good way of finding out about new services. Yesterday, it made me sign up for Backupify, a "social media backup tool" which will scrape your GMail / Delicious / Facebook / Flickr / Twitter / Blogger / Wordpress etc etc and store all the resulting data in a safe place on Amazon's cloud. Not a bad idea: the first 20 years of the Age of the Internet should have taught us, if anything, that data is ephemeral and can disappear at the flick of a switch. What happened to Geocities is proof that today's giants won't necessarily be with us tomorrow. Conscious of this state of things, Backupify gives you the option to drop your data on your own Amazon server, so that it will still be available if they go belly-up; quite a honest approach for a startup. It used to be a pay-only service, then went free to accelerate growth and get some venture capital; they will move to a freemium model after January 31, so you better try it out now if you can.
Good "Web 2.0" services usually expose APIs that make backups relatively easy for a programmer, but who's got time to write dedicated scripts AND the foresight to run them regularly? Myself, I've probably written half a dozen GMail scrapers, but I hardly ever ran them more than once. I've exported this Blogger-powered site once, and it was a nightmare. Backupify makes it very easy to "set up and forget", and that's good. The data will only be as good as what the various sites will allow; for example you will never be able to "restore" a Twitter account, so Backupify will only give you a PDF of your (and your friends') twits, which is the best you can expect. For Google Spreadsheets you get XLS files, for Blogger you get a big XML containing all your posts, etc etc.
The only problem with the site is the password anti-pattern: in order to get at your data, they often have to ask for your login details, and will store them on their servers. They do use OAuth if the service supports it (like Facebook or Google), but otherwise you'll have to trust them with your credentials. This makes them a very good target for black-hat hackers, among other things. I do hope they know what they are doing.