Grantlee 5.0.0 release candidate available for testing

September 22, 2014

I have tagged, pushed and tarball‘d a release candidate for Grantlee 5.0.0, based on Qt 5. Please go ahead and test it, and port your software to it, because some things have changed.

Also, following from the release last week, I’ve made a new 0.5.1 release with some build fixes for examples with Qt 5 and a change to how plugins are handled. Grantlee will no longer attempt to unload plugins at any point.

Grantlee 0.5.0 (codename Auf 2 Hochzeiten tanzen) now available

September 19, 2014

The Grantlee community is pleased to announce the release of Grantlee version 0.5 (Mirror). Source and binary compatibility are maintained as with all previous releases. Grantlee is an implementation of the Django template system in Qt.

This release builds with both Qt 5 and Qt 4. The Qt 5 build is only for transitional purposes so that a downstream can get their own code built and working with Qt 5 without being first blocked by Grantlee backward incompatible changes. The Qt 5 based version of Grantlee 0.5.0 should not be relied upon as a stable interface. It is only there to assist porting. There won’t be any more Qt 4 based releases, except to fix build issues if needed.

The next release of Grantlee will happen next week and will be exclusively Qt 5 based. It will have a small number of backward incompatible changes, such as adding missing const and dropping some deprecated stuff.

The minimum CMake required has also been increased to version 2.8.11. This release contains most of the API for usage requirements and so allows cleaning up a lot of older CMake code.

Also in this release is a small number of new bug fixes and memory leak plugs etc.

Grantlee based on Qt 5

September 10, 2014

While I’ve been off the grid I received an unusually high concentration of requests for a Qt5-based Grantlee. I’m working on getting that done for September.

I Did it My Way

September 10, 2014

I flew to Bilbao on the 11th of August and took a train to Burgos. From there I walked 500km over 21 days to arrive in Santiago. Although technically a Catholic pilgrimage, I approached it secularly as a walking holiday, a different environment while in-between jobs and some time for myself. Everyone walks their own Camino.

First Insight: There is suffering

On arrival in Burgos, I needed to first get a ‘Credential’, which allows sleeping in the albergues for Peregrinos along the route, and records qualification to recieve a Compostela at the end of the journey. A credential may be obtained from the municipal albergue in Burgos so that was my first stop. It was almost 8pm when I arrived and the Hospitalero had been telling people since 4pm that the albergue was full. However, he kept a spare bed for such late arrivals and luckily he gave it to me. It made for a good start.

Many sunflowers on the Meseta

Many sunflowers on the Meseta

Stated in a deliberately impersonal way, the nature of suffering on the Camino was immediately apparent when I arrived in Burgos. For most people (with sufficient time), The Camino starts in St. Jean Pied de Port in France from where pilgrims walk over the Pyrenees, and through Pamplona before arriving in Burgos two weeks later. Colloqially, this first of three stages of the walk is known as the ‘Camino of Suffering’, where the pilgrim starts the challenge and experience. I spent the first evening with a few people who had developed the blisters and the tendonitis, people who were bidding farewell to the journey already (some people do it over multiple years), and people who were bidding farewell to companions.

In the morning I got up at 6am and started walking in the dark out of Burgos, following the centuries-old route along the second stage – the ‘Camino of Death’, so called because of the barren, flat landscape surroundings until reaching Astorga.

Initially I walked with one Italian guy and we soon caught up with two more Italians. Most of the time walking the Camino is spent walking alone though, so that little group quickly dissolved as people broke away or fell behind (ahem!). A social shock I experienced is that when someone in a group stops or slows (even one more-familiar than a few hours/days), the others simply continue on – they’re sure to be re-united at a break-point or end point later along the way. It’s something to get used to.

My shadow's the only one that walks beside me...

My shadow’s the only one that walks beside me… I have tonnes of photos like this. Depending on whether I like you, I might sit you down to show you all of them!

Second Insight: Suffering should be understood

One of the things I learned on the Camino is that ‘normal’ is partly an environmental concept. It became ‘normal’ for me to get up at 6am, walk 20-30km per day, eat with some strangers and some familiar faces and go to sleep at 10pm. It did take about a week for that to become ‘normal’ (and even enjoyable!), but it is certainly not similar to my Berlin experience.



I had blisters since the first day of walking, but by the time I reached Bercianos I was no longer able to stand, let alone walk. I had a day off followed by a 7km walk to the next town where I happened to meet a foot doctor from Berlin who gave me all the help I needed, including her sandals. My footwear was the problem causing my blisters (I was walking in running shoes), so I bought myself a good, expensive pair of sandals when I got to Leon, gave the good doctor hers back and had no new problems caused by footwear for the next two weeks. What are the odds of a foot doctor having the same size feet as me?

Chica the dog

Chica the dog

Most of the people I encountered on the Camino were Italians, Spanish a close second, and plenty of Germans. I fell into a good rhythm with a group of Germans for the second two weeks which was nice. We spoke German as our common language.


Third Insight: Suffering (of my Camino) has been understood

Astorga is a beautiful town and it marks the transition of the peregrino from the ‘Camino of Death’ into the ‘Camino of Life’. The route through Galicia is much more steep than the previous stages and full of the sights, sounds and smells of dairy farms. Most of the milk produced in Spain is produced here. The sunflowers filling the landscape and the trail are long since gone.

Although the blisters did not return, the steep climbs and descents brought with them some tendonitis for the final two days of walking. Not much to complain about, timing wise.

It’s sad that the experience of walking the Camino can’t be captured by any camera or prose, but must be experienced to be understood. That’s just part of the nature of suffering :).


Like many, I continued on to Finisterre for a few days of sleeping on the beach and unlike most I spent the weekend after in Barcelona, for a very different experience of parks and beaches.

Grantlee 0.4.0 (codename ARM, aber Sexy) now available

November 28, 2013

The Grantlee community is pleased to announce the release of Grantlee version 0.4 (Mirror). Source and binary compatibility are maintained as with all previous releases.

This yearly custom is becoming an annual tradition. The most significant change in this release is a bump of the CMake version requirement. The required version is now at least CMake 2.8.9. This means that I can start using some more-recent features such as CMAKE_AUTOMOC and clean up all the code, but it isn’t high enough for the latest toys.

Grantlee is used in several places throughout KDE now. At least KDevelop, Skrooge, Rocs are using it, as well as several places in KDEPIM. The KDEPIM uses are also growing as Laurent finds excuses to use it :). I was also approached at Qt Developer Days this year by someone who uses Grantlee internally in his company for code generation. “What’s your connection to Grantlee?” – “Erm, I wrote it :)”.

As I’ve also been working on embedded projects lately, I also made sure Grantlee builds and works on the RaspberryPi. This is the first release which passes all tests on such ARM systems, because Qt treats floating point numbers differently there.

Share and Enjoy!

Grantlee 0.3.0 (codename Leistungswasser) now available

November 1, 2012

The Grantlee community is pleased to announce the release of Grantlee version 0.3 (Mirror). Source and binary compatibility are maintained as with all previous releases.

This release arrives almost a year after the last release and my previous blog post here. Meanwhile, I also created a new word, as commonly happens to anyone speaking German. When asking for ‘tap water’ (Leitungswasser) at a restaurant, I mistakenly asked for ‘performance water’ (Leistungswasser). When it’s water you need though, it might just as well be performance water.

As I noted in that last release, I had become interested in code coverage, and improving that was the focus of the 0.3.0 release. The some results can be seen comparing old with new in the core templates library for example, where I managed to bump line coverage to 100% in some more files, and made significant gains in others. The testcocoon tool was very useful for finding dead code too in places where I hadn’t expected it. There is still some low-hanging fruit there to increase the coverage stats, which will probably make the next release.

Also in this release is an implementation of the dictsort filter, special size and count properties on containers (eg You have {{ apples.size }} apples.).

In the textdocument library, a new patch from Laurent Montel makes it possible to generate item lists in plain text and html using Roman Numerals.

Grantlee v0.2 (codename Doppelt-gemoppelt) now available

November 3, 2011

The Grantlee community is pleased to announce the release of Grantlee version 0.2 (Mirror).

This release is source and binary compatible with the 0.1 series. Initially I thought I’d be able to make the 0.2 release in August with few changes other than the version number bump. Linux 3.0 was just out at the time and I thought it would be fashionable, but I kept finding new things to get done. Besides I have trouble counting past nine (zero-indexed) without taking my socks off.

For the benefit of the uninitiated, Grantlee is a set of Qt based libraries including an advanced string template system in the style of the Django template system.

  {# This is a simple template #}
  {% for item in list %}
    {% ifequal item.quantity 0 %}
      We're out of {{ }}!
    {% endifequal %}
  {% endfor %}

String template systems are very common in the world of web frameworks. In such web frameworks it is common common requirement to decouple data retrieved from a database and processed in some way from the presentation of that data. Typically it is presented in the form of html output, so most string template systems are optimised for html output including special handling of html entities and protection from cross site scripting exploits.

In the context of Qt, we already have several ways to separate data from its presentation in user interfaces. Apart from the more low level model view framework we have the more recent addition of QML for flexible QMetaObject and property based relations.

Grantlee is also in an abstract sense a QMetaObject based language, though it can be extended beyond the qmetaobject apis too. It is not suitable for user interfaces comparable to the way QML is though. Grantlee is more suited to creation of static output suitable for theming, and reports iterating over already processed data, which is recreated on demand and non autonomously, unlike QML. This of course is suitable for markup based user interface with stateless data connections. I wonder if there is a usecase for creation of locally processed static data based on varying inputs which is automatically regenerated when those inputs change which is not already satisfied by QML. Something to investigate in the future perhaps.

At about the same time though i discovered testcocoon and have been working with testcocoon developer S├ębastien Fricker on coverage instrumentation for Grantlee. The motivation is more generally about learning how to use testcocoon with Qt and CMake projects. This is in anticipation of making it possible to gather coverage data for KDE productions in the future. The effort has led to a good deal of work by S├ębastien on both testcocoon itself and on Grantlee to ensure useful coverage data collection. Some of the changes required relate to specifics of loading plugins, some crash fixes, and some issues associated with buildsystem integration and peculiarities of unit testing private api.

The result is some clear indications of what parts of Grantlee are adequately unit tested, and which are not. There are some false positives still produced by testcocoon such as in unit tests but I’m confident that will continue to improve. The good news is that most hard parts of Grantlee are unit tested. Ideally there should be no such thing as an edge case when considering what should be unit tested though. Increasing the coverage stats of Grantlee will be a focus for the next while. The coverage report generated by gcov and lcov is also available for this release.

Coverage result for part of Grantlee

Another set of changes since the 0.1.9 release is concerned with the buildsystem. I’ve learned a lot about CMake since starting with Grantlee; and I have been able to apply that knowledge to increase the 0-knowledge portability of Grantlee. 0-knowledge portability refer to the portability of Grantlee to platforms I have no access to. Features are enabled as much as possible by testing their availability rather than testing for platforms known to support certain features. For example some of the Grantlee unit tests require some third-party containers for testing. I’m able to test for both tr1 and boost to use as third parties when running those tests.


Grantlee v0.1.9 (Codename affengeil) now available

June 24, 2011

The Grantlee community is pleased to announce the release of Grantlee version 0.1.9 (Mirror).

This release contains the usual round of bugfixes, features, documentation updates and a new example application. The use of funny german vernacular for codenames continues.

Notably absent from this release is the work on Grantlee::Tubes. The QIODevice API needs a bit more research, so those classes will appear in a future release instead while I figure out what parts of the QIODevice API can be relied upon.

Much of the directed effort in this release has been on the build system. With the help of Alex Neundorf, the entire CMake system was updated to make Grantlee easier for consumers to consume. This includes installing EXPORTS from Grantlee which can be imported with find_package, proper RPATH handling, and reducing hardcoded paths in convenience properties.

A follow-on from the CMake work was to add some CPack configuration. Now it is possible to create binary tarballs for Grantlee as well as a Windows install wizard. CPack makes the process very easy once everything is set up.

The Grantlee component installer for windows.

In an effort to make generation of content where whitespace is not insignificant, I’ve added a smartTrim feature to Grantlee (based on an idea in the Django bug tracker which I’ve been pushing forward simultaneously). The idea is to discard insignificant whitespace while processing the input content. Whitespace can be considered insignificant if there is only one piece of template syntax on a line.

This feature should make it easier to write templates to generate C++ code for example. For html output, whitespace is rarely significant.

The efforts around introspection of QObject derived types in QVariants did not lead to improvements in Qt4. It is possible that improvements will be made to the introspection system in Qt5, but the features could not be added in a binary compatible way in Qt4. The Qt4 solution is more documentation.

I also added some more documentation on the examples shipped with Grantlee along with links to the brilliant prose in these blog entries.

GCov based coverage data is now also going to be produced for each release. The existing coverage data shows that Grantlee has excellent test coverage in most parts – 90% of functions are covered and 85% of lines in the libraries and plugins. Most of the non-covered code indicates missing tests for failure cases, but the ‘happy path’ is generally well covered. There might be some advantage to using CTest and CDash for coverage information. Something Grantlee coverage scripts can do that I don’t think CTest can though is to break down the coverage data by the unit test that contributed to it. This might help identify where a completely new test is needed to purposefully cover a class.

Coverage of Grantlee::Context. Break down by unit test

Because much of the effort in this release went into improving the buildsystem, it should be much easier now to add new libraries to Grantlee, so I expect that to happen in the next release with Grantlee::Tubes.

Holy Cheese Batman!

June 1, 2011

* What?

* Uh, the cheese. It has lots of holes in it…

That’s right. I’m in Switzerland

I was a bit cryptic in my last post, though posts from others may be more clear that I’m at the Platform 11 sprint. There is a growing list of discussion topics, but the final list of topics will be determined at runtime.

It seems though that there is a lot of stuff to untangle here.

Untangling this is going to be a lot of work

We’re going to spend the next 6 or so days talking about the future of the KDE platform, the future of the KDE libraries, what we should decouple and what not, what Qt 5 means for KDE, the relevance of QML etc. All the stuff that everyone else is wondering about, we are too, and there are about 20 people here in Randa Switzerland, to discuss it in high volume, high bandwidth and low distraction.

There is another few sprints co-located in time and space to discuss Nepomuk, Amarok and KDevelop, so in total we are about 60 people concentrated in a tiny village. This might be the highest concentration of KDE developers compared to ‘normies’ in a single place ever.

It’s been an evening of arrivals and re-acquainting with familiar faces. I finally got to meet Gregory Schlomoff in person too and catch up with what is happening in BetterInbox. This is sure to be a good sprint.


May 31, 2011

Since my last blog, a few more bugs have been fixed in the KDE PIM 4.6 branch, so we’ve put out another RC release. This will likely become the final 4.6 version that gets tagged in a few days and released next week.

I’ve been trying to make clear that this is a usable, if not entirely bug free (or regression free) release. There is no need to fear it, but do try it. Returning to KDE PIM 4.4 may mean you lose trivial information like emails you marked read or important while using 4.6, but certainly not world-ending information loss that can never be recovered.

Still we do consider this a release worth switching to for many people. KDE PIM 4.6 will not fix all problems of all users of 4.4, but it puts us on track to get there.