A QtQuick / QML preprocessor, the Q’n’D and KISS way

Lately, I have been porting the existing code base of QuasarMX to Qt 5. While the C++ core was migrated in almost zero time, porting the QtQuick 1 code to QtQuick 2 was not as straight forward. In a small experiment I decided to change “import QtQuick 1.1” to “import QtQuick 2.1” in all of the 600 files, to see how far that gets me. To my amusement it actually worked for almost all files. I only had to make some QtQuick 2 specific changes due to changed behavior in the new engine.
I hate to duplicate my code bases, especially if I still have to support platforms that only support Qt 4.7+ and QtQuick 1. It puzzles me how there is no preprocessor / macro functionality available in QML, especially if – like in my case – 99% of the QtQuick 1 code runs on QtQuick 2 without any modification other than changing the import section. Talk about detachment from reality…

So, here is a very quick-and-dirty preprocessor that will rewrite the import section and also apply line changes based on defines. It is inspired by the very simplistic notation of the preprocessor used in Octatask (paper), but the implementation is new. The preprocessor does not change the line count of the preprocessed files (read: debuggable) and preprocessing is reversible as no information is lost (read: unused lines are commented).

It is available here:
https://svn.katastrophos.net/kcl/trunk/qmlpp/ (yes, that is a Subversion repository)

The preprocessor is contained in the sub-folder “src”. It is comprised of the qmlpp.pri file for easy inclusion in your .pro file and qmlpp.sh, which is the Bash script doing the fancy substitution work (read: sed running humongous regexps). If you are using this on Windows, make sure to install Cygwin and put the location of bash.exe into your system’s PATH variable.

The sub-folder “test” contains an example project, that will compile and work on both Qt 4 / QtQuick 1 and Qt 5 / QtQuick 2. Check it out to get a feeling what you need to change to make your code work on both versions of the toolkit.

In your application’s .pro file you basically add the following code:


target_qtquick1: qmlPreprocessFolder(yourQmlDirectoryHere, @QtQuick1, 1.0)
target_qtquick2: qmlPreprocessFolder(yourQmlDirectoryHere, @QtQuick2, 2.0)

The exported function is defined as:

qmlPreprocessFolder(folders, defines, rewriteVersion)
  • folders: One or more folders relative to the $$PWD, separated by space. Example: qml js
  • defines: One or more defines to set, separated by space. Defines always start with @. Example: @QtQuick2 @Android
  • rewriteVersion: This defines the version to rewrite the line “import QtQuick x.y” to. Example: 2.1

In your code you can now set the defines as marker comments in the style of //@DEFINENAME:

@QtQuick1 define set:

     someFunctionSpecificToQtQuick1(); //@QtQuick1
     //someFunctionSpecificToQtQuick2(); //@QtQuick2

@QtQuick2 define set:

     //someFunctionSpecificToQtQuick1(); //@QtQuick1
     someFunctionSpecificToQtQuick2(); //@QtQuick2

This works for both .qml and .js files.

You can also stop the preprocessor from rewriting the line containing “import QtQuick” by adding the “//!noRewrite” marker comment to it:

import QtQuick 1.1 //@QtQuick1 //!noRewrite
//import QtQuick 2.0 //@QtQuick2 //!noRewrite

This is useful in those situations where you need more fine-grained control of the rewrite process.

Once you run qmake again, the QML preprocessor will rewrite your files. Make sure to save any pending changes before. I am working on a more generic and safe method of including the preprocessor to possibly rewrite the files during deployment-time or run-time.

The tool is also available via command line. This is useful for when you are rolling your own deployment scripts or if you are using CMake.

usage: ./qmlpp.sh [options] <filename JS or QML or directoryname>

   -h                Show this message.
   -q <major.minor>  The version of QtQuick to rewrite to. Example: -q 2.1
   -d <defines>      The defines to set, separated by |. Example: -d "@QtQuick1|@Meego|@Debug"
   -i                Modify file in-place instead of dumping to stdout.

QuasarMX, Qt, QML and the experiments

Some of you following my micro-blogging on Twitter might already know about it: In the last few months I have been busy developing a new application. What initially just started out as a re-write of the user interface of Quasar Media Player has turned into a completely new application called QuasarMX. It is based on the very core of Quasar Media Player but stripped of all the legacy and third-party code. The completely new UI is based on Qt Quick / QML, a new technology which simplicity and elegance I fell in love with over the past year. For me QuasarMX also marks the start of two experiments:

1. How many platforms and operating systems can I port my app to?
2. Is there any commercial viability at all in publishing the software to various app stores (Nokia Ovi store, Android Market etc.) ?

The first experiment is important to me. Now that Nokia put the Qt project into open governance, the Qt community has the unique opportunity to extend primary platform support to Android, iOS and possibly even Windows Phone 7, thus extending the possible market cap and audience for mobile apps based on Qt dramatically. This experiment is largely about experiencing first hand what changes are required to get my application running on these platforms and as a matter of fact what needs to be done in projects like Necessitas (Qt on Android) to make that goal happen.

As for the second experiment I am actually just interested in getting to know the mechanics of the various app stores. I am pretty confident that there is little to no money to be made from yet another music player app. Yet, it is still interesting to see what happens, what works and what not, especially in regards to future apps.

In July Nokia accepted my application and invited me into the Qt Ambassador program. As part of this program Nokia loaned a N950 developer device to me, which I extensively used to develop and test the Harmattan UI for QuasarMX. The new user interface is very much inspired by the simplicity of the MeeGo Harmattan Swipe UI.

As of yesterday the open Beta 1 of QuasarMX is available for the Nokia N9 and N950. Releases for other platforms will follow shortly.

FHEM module for ELV ESA1000 (WZ/Z/GAS) series of devices

FHEM, the amazing home-automation server software, already has support for several sensors, meters and switches produced by ELV. In October 2010 I bought two meters, ESA1000WZ and ESA1000GAS for my house in the hope that FHEM would support them. Unfortunately it did not (at the time). I quickly found some hints that somebody, namely Gerd K., was working on adding support. So I contacted him and a day later received his module for testing. In the meantime eager in anticipation I was hacking away, duplicating the existing EM1000 extension and customizing it to read the raw strings coming from my Busware.de CUL 868 MHz USB adapter. While I got the power meter’s values (ESA1000WZ) figured out pretty quickly, it was a bit more involving to get correct readings from the gas meter (ESA1000GAS). Unfortunately Gerd’s code did not include support for the gas meter, so I emailed him my changes, but sadly never received feedback.
So today I am releasing my code on a works-for-me basis:


UPDATE:Patch for FHEM 5.3 Version: Feb 10th 2013 for FHEM 5.3
Package for FHEM 5.0 Version: Oct 25th 2010 for FHEM 5.0

  • Supports ESA1000WZ power meter (infrared version, possibly others as well)
  • Supports ESA1000Z and ESA1000GAS gas meters (infrared version and version using impulse transducer for the Elster-Kromschroeder BK-G4)
  • Features proper graph files to plot current and cumulated day/month consumption

Photos / Screenshots


If you are using FHEM 5.3, please download the tar-ball version (or SVN version for that matter) and directly apply the patch cul_esa-for-fhem-5.3.patch.

UPDATE 2: Here is a completely patched version based on the tar-ball version of FHEM 5.3: fhem-5.3-cul_esa.tar.gz Version: Feb 10th 2013

If you are using FHEM 5.0:
Copy 19_CUL_ESA.pm and all .gplot files to your FHEM directories.
Sadly adding autocreate support and extending the CUL module to understand the raw message strings requires patching. Check cul_esa-for-fhem-5.0.patch to patch the files. This was diffed against the Debian package of FHEM 5.0. The very same version of FHEM as tar.gz has some differences in the sourcecode and some files missing. I contacted the author of FHEM about this issue but he has not updated the packages yet. So if you run into issues here it is probably due to these differences.

UPDATE 1: Here is a completely patched version based on the Debian package of FHEM 5.0: fhem-5.0-cul_esa.tar.gz Version: Oct 25th 2010

Here are some notes in German I made while developing the module, mostly concerning the different behavior of the ESA1000GAS compared to the ESA1000WZ:

Der ESA1000GAS mit dem ESA1000Z-Messgerät verhält sich leider anders als das ESA1000WZ, sodaß ich wieder die Korrektur-Faktoren einbinden mußte.
Ich konnte nicht herausfinden, wozu der übermittelte Tick beim ESA1000Z dient. Zwar ändert sich dieser mit geänderter Zählerkonstante, allerdings ergibt der Wert im Zusammenhang mit den von der Einheit übermittelten Werten keinen Sinn, sodaß ich hier direkt mit der Zählerkonstante multipliziere, um die Kubikmeter zu erhalten, und dann zusätzlich noch mit dem Umrechnungsfaktor (bei der EWE ergibt sich dieser aus der Zustandszahl * Brennwert Hs) multipliziere, um die Kilowattstunden aus der Gasmenge zu erhalten.
Leider ändern sich damit die Parameter bei der Definition:

define CUL_ESA_286 CUL_ESA 1925 286 1 1 23.086
corr1 = corr2 = 1 (und damit wirkungslos)
CostPerUnit = 23.086 Cent/kWh

define CUL_ESA_798 CUL_ESA 1429 798 0.001 9.5154 4.5339
corr1 = 0.001
corr2 = 9.5154 kWh/m3
CostPerUnit = 4.5339 Cent/kWh

Ich habe ebenfalls noch einen Durchschnittswert in Kilowatt implementiert, sodaß man die Durchschnittleistung einigermaßen sinnvoll in einem Diagramm darstellen kann. Hier gab es allerdings bei meinem Drehstromzähler Probleme mit Unterabtastung, weil sich die Drehscheibe bei geringem Verbrauch zu langsam dreht, sodaß das Meßgerät zwischendurch schon Nullwerte zurückmeldet, weil kein Impuls eingegangen ist. Dafür habe ich einen entsprechenden Schwellenwert bei der Berechnung des Durchschnittswertes implementiert. Nicht schön, funktioniert aber für meine Zwecke.

Quasar Media Player 0.96 beta 4 available

Quasar Media Player

I am pleased to announce beta 4 of Quasar Media Player.
This new version introduces some new features and big improvements in terms of performance and memory-usage.
The previously separate last.fm Audioscrobbler QScrobbler has been integrated into Quasar as add-on.
This release also marks the introduction of the Cover Art Downloader which uses the new open-source katastrophos.net Cover Art search engine to download cover art images for the new Cover Art Flow album browser.

Quasar Media Player on Windows 7Cover Art Downloader on OS X

Binaries for the previous platforms (Sharp Qtopia and pdaXrom) along with new binaries for Windows and OS X (universal) are available on the project’s homepage.

Nightly Builds of Quasar Media Player available

Quasar Media Player

It’s been some time since the last update. In my previous post I mentioned I was in the process of setting up a nightly build system. This system has been running silently since May.
I guess it is finally time for me to officially announce the nightly builds of Quasar Media Player:


Along with the most current sourcecode tarball, binaries are available for 4 platforms:
Windows (win32), OS X (universal binary), Sharp Qtopia and pdaXrom Linux (both for Zaurus PDA)
The Windows version comes in two styles: a generic setup (EXE) and a self-contained portable version (7z archive)

Enjoy and please leave a comment.

Setting up the Inno Setup compiler on Debian

I’m currently setting up a nightly build system for Quasar on my Linux box which is running Debian. This system also cross-compiles Quasar for Windows.
The Windows version of Quasar is going to be available in two fashions: one self-contained, portable version and one version that can be installed.
I’m not a huge fan of installers. But when it comes to creating a setup program for a given Windows application I’m quite accustomed to Inno Setup having used it for years. Unfortunately there is no native Linux version of the Inno Setup compiler available for Linux. NSIS exists as package for Debian but I am not fond of using it, largely because I am a Delphi guy. :)
So, here is a small guide on how to get the Inno Setup compiler up and running on Debian:

First step is to install Wine either as super user or by using sudo:

sudo apt-get install wine

As normal user fire up your X server and your favourite terminal application and get the latest Inno Setup QuickStart pack:

mkdir /tmp/innosetup
cd /tmp/innosetup
wget http://files.jrsoftware.org/ispack/ispack-5.2.3.exe
wine ./ispack-5.2.3.exe

This will start the installer in Wine. Note, for the installation you will need a running X11 server since the installer obviously is graphical. If you have not set up Wine before, the default location C:\Program Files\Inno Setup 5 will install to ~/.wine/drive_c/Programme/Inno Setup 5.

Luckily the Inno Setup compiler offers a command line interface, ISCC.exe, which will run in Wine without the necessity of having a X server running. So it is ideally suited for automated runs.

Here is a simple wrapper shell script called iscc:

[ -f "$scriptname" ] && scriptname=$(winepath -w "$scriptname")
wine "C:\Program Files\Inno Setup 5\ISCC.exe" "$scriptname" "$2" "$3" "$4" "$5" "$6" "$7" "$8" "$9"

I installed this script in my local bin directory (~/bin) and added it to the PATH environment variable.
This will allow running the Inno Setup compiler from anywhere and it also makes it very easy to integrate into a build script. You can even feed a script via stdin, e.g. something like:

iscc - < ./myscript.iss

Implementing the “Reveal In Explorer” functionality

Update: I seems like Microsoft changed the behavior of the Explorer’s command line parameters in Vista and Windows 7. Below is the fixed version of my code that addresses the problem.

So, I was wondering the other day how to implement a functionality similar to Firefox’s “Open Containing Folder” or OS X’s “Reveal In Finder”.
It turned out to be extremely simple. Here is the Pascal/Delphi-Code:


function RevealInExplorer(const Filename: string; ShowExplorerWithFoldersBar: Boolean = True): Boolean;
  Params: string;
  if FileExists(Filename) or DirectoryExists(Filename) then
    Params := Format('/select,"%s"', [Filename]);

    if ShowExplorerWithFoldersBar then
      Params := '/e,' + Params;

    ShellExecute(0, 'open', 'explorer.exe', PChar(Params), nil, SW_SHOWNORMAL);

    Result := True;
    Result := False;

Lazy source code comment stunts


Here is a simple way to disable or enable whole code blocks with just two slashes:

PHP / C++:

  Block (commented block)
  Block (active block)

Object Pascal/Delphi:

  Block (commented block)
  Block (active block)

Alternatively you can use { and } in the Object Pascal/Delphi example.

Double-Slash-Whole-Block-Switching (Object Pascal/Delphi only)

The Object Pascal dialect used in Delphi supports three ways of commenting code, two for commenting whole blocks ( { } and (* *) ) and one for commenting lines ( // ).
We can exploit this feature to switch between two code blocks easily and fast:

Block 2 is in the enabled state:

  Block 1  (commented block)
  Block 2  (active block)

Note, I am just adding two slashes in front of the first comment block to activate it again – similar to Double-Slash-Whole-Block-Commenting trick above. This will also magically disable the second block due to the way the comment marks are arranged:

  Block 1  (active block)
  Block 2  (commented block)

These tricks are probably applicable to other programming languages as well. Please let me know.

Q…/Free: Bug in QProcess writeToStdin

All right, this post is just to stop somebody else’s suffering in figuring out why writing to stdin in QProcess on Version 3.3.x-8 of Q…/Free doesn’t work on Windows. Well, actually it works but just for the first line you write to stdin. There is a bug in qprocess.cpp at line 730:

void QProcess::writeToStdin( const QString& buf )
    QByteArray tmp = buf.local8Bit();
    tmp.resize( tmp.size() - 1 ); // drop the implicit \0
    writeToStdin( tmp );

should be:

void QProcess::writeToStdin( const QString& buf )
    QByteArray tmp = buf.local8Bit();
    tmp.resize( buf.length() );
    writeToStdin( tmp );

Verision 3.3.7-7 includes the latter method, same as the latest Qt 4.3 sources. So, it’s actually a regression in 3.3.x-8. If you require the latest Qt 3 / Q…/Free for your open source application and need to write to some other processes’ stdin, you can just use a wrapper workaround that uses the latter method and directly uses writeToStdin( const QByteArray& buf ) instead of the QString variant.

rdesktop: Connect to Windows 7 and Vista with ClearType font smoothing enabled

So Windows Vista finally allows to enable ClearType font smoothing for Remote Desktop / Terminal Services sessions. Update: Windows XP SP3 does too!
If you try to connect to a machine running Windows XP SP 3 or later using rdesktop, you won’t get smoothed font typing since at the time of this writing rdesktop does not officially offer an option to control this feature. However, here is a workaround:
Continue reading “rdesktop: Connect to Windows 7 and Vista with ClearType font smoothing enabled”