Having owned an N900 for a little while now (casting my vote for openness and freedom in the mobile space), I've been eagerly waiting for a MeeGo release that I could install on my N900 and play with. That moment came a little over one week ago! :) So, after waiting for my nice new class-10 microSDHC card to arrive (cheaper to buy online with shipping, than to buy locally), I finally had a play last weekend. I was a little dissapointed :|

Although I had expected a lot of bugs and instabilities, and my overall expectations were quite low at this stage, I was still quite surprised at just how incomplete MeeGo Handset is. I guess my unrealistic expectations stemmed from the fact that the current MeeGo handset release has the version number "1.1" - that implies to me that it should be "fairly complete" (albeit with bugs, etc). However, it is more inline with what I would call a version "0.1".

I've been experimenting with QtSvgDialGauge in a personal project, and so far, I like it a lot! :)

For those who don't know, QtSvgDialGauge is nice SVG-based dial/gauge widget, which is part of the Qt Embedded Widget demos. You can see it (and several other embedded widgets) in action in the Qt Embedded Widgets Catalog and Qt Patient Care Demo applications. And you can download the source for both applications here.

Now, the Qt Embedded Widget demos includes three SVG-based skins for the QtSvgDialGauge class: Tachometer, Thermometer, and Amperemeter...

With most non-trivial Qt projects that I create, I like to include a pre-pre-build command in the qmake project file. I'll explain why as we go, but first off, let's look at what I mean by "pre-pre-build" (it is not at all a standard term).

The typical build process (as performed by make) looks something like this:

1. For the given target, check if any of the target's dependencies have been updated since it was last (re)built.
   
   1. If no dependencies have changed, do nothing - we're done ;)
   2. If one or more dependencies have changed, then:
      1. Build each dependent target.
      2. Build this target.
      3. If appropriate, link this target with its dependencies.

That is, of course, a gross oversimplification... but it will do the purpose of this post.

Now, like most Qt developers, I use qmake to generate the Makefiles that drive the build process. Qmake, being an excellent tool, allows you to customise the generated Makefiles in many, many ways. For example, you can add custom commands to be executed just before or after the link step (1.b.3 above) via the QMAKE_PRE_LINK and QMAKE_POST_LINK variables.

However, qmake does not provide a QMAKE_PRE_BUILD variable for adding pre-build commands, and certainly no QMAKE_PRE_PRE_BUILD variable either. The former, it turns out, is pretty easy to achieve anyway, but the latter (the topic of this post) is a little bit trickier.

Most people who know me will be somewhat surprised by the title of this post... but it's true. I do, indeed, enjoy the current iPhone craze - simply because I think some good is likely come of it :)

Specifically, there's two main positive things that I think may come from the current iPhone craze: