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.

Whoa!! I just got a rather surprising (to me) warning from Gmail. It reads:

You are almost out of space for your Gmail account.
You can view our tips on reducing your email storage or purchase additional storage.

As I said, this was a bit of a surprise to me. When I first began using Gmail, I kept a close eye on my storage usage, but it used to climb so slowly that I soon forgot all about it. But upon seeing the above message, I quickly glanced down to read:

You are currently using 6989 MB (95%) of your 7356 MB.

Since Google released Chrome last year, I've gotten used to regularly using two browsers on my PC: Google Chrome for all of my "simple" personal browsing such as webmail, and Firefox for more advanced browsing such as website development. This also tends to create a nice separation of personal (Chrome) versus work (Firefox) tasks.

However, one thing that has bothered me for some time is the (slightly) proprietary nature of Google Chrome... don't get me wrong, Chrome is built from the opensource Chromium project, so it's not all *that* proprietary, but still, something does not quite sit right with me.

Back in part 1 of this build, I ran in to some overheating concerns with the northbridge. So I decided to try a passive tower cooler for both the north and south bridges.

So here's the new parts that are ready to go... from left to right, they are:

• Thermalright HR-09S (type 3) VRM cooler... which I didn't end up using (more on that later);
• Thermalright HR-05 IFX chipset cooler - this is the straight-up version, which I'll use for the southbridge;
• Thermalright HR-05 SLI IFX chipset cooler - the "bent" version for the northbridge.