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.

Hysterical Raisins

May 30, 2011

I often see software developers who use Qt looking for existing solutions and libraries. Developers using Qt want IMAP libraries, a way to create Tar files, and more.

Many such cool classes and features are part of the KDE libraries, but are rarely considered by developers using Qt. To them it seems that KDE is bloated, or maybe that depending on KDE just for creation of Tar files is unrealistic. To a large extent that is false, as libraries from KDE come in granular form already. The kdecore libraries take up just 2.5 MB of space. The kdeui libraries consume 3.7 MB of space. For comparison, QtGui is an 11 MB binary. Parts of the KDE libraries already depend only on Qt, such as Solid, the hardware abstraction.

So it is true that we’re not doing at all badly already, but there are still areas we can improve. Part of that extra work is in communication (*cough*), packaging and build system improvements which have already been happening across the whole contributorship. It’s really great that I can run a command like

  debtree libkimap4 | dot -Tpng > kimap.png 

and get an image showing just how few dependencies there are these days for KIMAP.

Historical Reasons

However, there are still some interdependencies in the KDE libraries that may make adoption more tricky. You can’t have the plugin system or the asynchronous Job APIs without pulling in the localization system and the configuration system. This is the case largely for historical reasons and to some extent it is also possible to lessen that impact, but the currant state is that people who want to use parts of the KDE libraries fork the parts they want, and leave the rest.

I recently came across a word the Germans use to recognize situations like this in just a single word: Rosinenpickerei, translated as raisin picking. At first I thought, wow – The Germans have taken the concept of ‘Choosing the required/desired parts of a whole, and leaving the rest behind’ and squeezed it into a single word. Then I realized it was just like cherry-picking in English, so nothing to get all stereotypical about.

Turning it up to 11

Recognizing room for improvement, the KDE community organized a developer sprint meeting to focus on the platform and libraries right across the board. We’ve been running on 10 all the way up to now, and have come to the question of where can we go from here? We need that extra push over the cliff, so y’know what we do? We turn it up to 11. We have a in person face to face meeting for an entire week to tackle issues such as how we can improve Qt to make KDE software better. How we can improve KDE libraries to make the lives of Qt developers easier, and how we can improve the KDE platform to increase consistency among KDE applications.

That’s right,

Data fragmentation between ‘owning’ services?

May 17, 2011

I saw a snippet recently pointing to a concern about data fragmentation relating to Akonadi.

After talking with doctormo about it, the concern seems to be that there are a lot of services and applications trying to be the single standard point of access for PIM data.

From my standpoint (biased obviously) I don’t think it is a relevant issue for Akonadi using applications, because Akonadi is designed exactly to deal with the data fragmentation issue, by consuming PIM from other locations. For example, contact details from pidgin can now be made accessible in KAddressBook:

Pidgin and KAddressBook sharing data

Here’s how that happened:

After digging around I found that Elementary is an Ubuntu derivative which is making some new applications, such as postler, an email application. I couldn’t find any ‘backend’ for postler. It seems to talk directly to dexter, the addressbook application. If the two applications catch on, that would be additional places that your data would exist or need to be copied and possibly get out of sync, and could mean that dexter must be running in order for postler to have access to addressees. I couldn’t find a SCM repo to check if that is the case.

Postler and dexter don’t use evolution-data-server as a backend either, preferring to avoid it for whatever reason. Akonadi was likely never considered by the postler developers because they might think it depends on something fictional like the KDE desktop environment, which is clearly not the case. The point is though that non-adoption of common infrastructures between different applications is usually a social, communication and perception problem, but not a technical one. That can lead to the kinds of data fragmentation and inter-application dependencies which we saw between KDE 3 applications and which appear to exist between postler and dexter.

Those who have followed Akonadi development will know that PIM applications in KDE PIM 4.6.x do not own the data they show. KAddressBook does not need to be running or even installed in order for KMail or KOrganizer to access contact information for people. The reason is of course that KAddressBook does not own the data. Even Akonadi does not own it, but just provides access to it from third party data providers.

This is the primary distinction between data syncing between applications and data sourcing by applications. Syncing requires that one-to-one copies be made (and kept up to date) of ‘shared’ data between collaborating applications, possibly between differing formats or data representations and different transport mechanisms. However shared data allows many-to-many relations where all applications can access all data with zero knowledge of the other applications. Because no application owns the data, there is less work needed to prevent them getting out of sync with each other.

Akonadi is designed to address the problem of data fragmentation, by knowing the various sources of PIM data, and making all of it available to applications. The applications don’t need to know where Akonadi gets the data from. It only needs to get it from Akonadi and not concern itself with the true origin.

This means that if it came to it and people wanted to share data between dexter and Akonadi based applications, it would be possible. A somewhat more interesting project, for various reasons, from the GObject side at the moment is folks. Folks is designed to aggregate information about individual people between multiple different applications, comparable to the PIMO::Person concept KDE people might be more familiar with.

There are Qt bindings currently under parallel development with the GLib/QObject based library, which means that if PIM data from Gtk or GNOME based applications are made available to folks, making that same data available to KDE applications is as simple as writing a new Akonadi resource for it.

Because the Qt bindings implement the QtContacts API, a generic Akonadi resource for that API works for any implementation of it. So even the Akonadi backend for folks doesn’t have any direct knowledge of the folks system. I created a proof of concept for exactly that this week, allowing to access contacts from pidgin in KAddressBook. With the roadmap for Qt-folks, it could become more useful for data sharing going forward.

Thanks to Martin and to Travis for reviewing this post and providing feedback.


May 15, 2011

The Kontact2 release train rolls on. Today we fixed the last of the release blocking bugs and tagged the release candidate.

It seems that many people around the Internet are as excited about the new release as we are. The message that this is not a bug-free release seems to be getting through. There will be bugs to annoy users, but the applications are usable and useful and they work without crashing and without losing data. The reports on my last post (which will of course be forgotten without non-duplicate bug reports :)) indicate normal-to-low severity bugs which would be expected in any Free Software, much less a release of a platform re-architecture and multi-application port and rewrite.

This version will have regressions compared to KDE PIM 4.4. There was never a goal to create a Kontact2 with zero regressions. The only goal was to create a working release. After that the work on making it perfect can begin. Division of resources between maintaining the 4.4 series and attempts to perfect the Kontact2 release was causing demotivation in the community. Making the release is the act that allows us to cross the starting line towards fixing the smaller issues.

Prepare to land!

So, onwards and onwards. The tagging of the release is due to happen on June 2nd before a release alongside with the 4.6.4 KDE SC, so all fixes and translations which are in the source tree get in:).

The next step: Coisceim

May 2, 2011

Using cloud services for your network and data gives away your control over your network and data. I read with interest about how Ars Techinca lost both temporarily, and told stories of how other people who don’t have the weight of a well known news website behind them to get it back. If you depend on cloud services for your network and data, they are not your network and data. You just have the privilege of being able to access them, which can be taken away for any or no reason. Usually the TOS of such services say as much. That doesn’t matter though as you didn’t read the TOS anyway.

Usually the main features of such services are access anywhere, aggregation, customized visualization and social features like uploading your picture and allowing everyone to consume your data. These are things which can be provided to some extent by locally installed applications too.

The new KDE PIM platform allows local aggregation of many different types of data. The aggregation is a feature in itself. As PIM data is part of the KDE PIM Platform, and not individual applications, this allows a departure from applications which focus on a single type of data or protocol (such as KMail -> email, KAddressBook ->contacts, KOrganizer -> events), to a focus on what the user is doing or trying to achieve.

In the old KDE PIM Platform applications owned the data and provided a scriptable access interface to it over D-Bus. In the new platform however, applications only provide a user interface to the data, and the data interface is provided by Akonadi. That makes the applications themselves far smaller, making it easy to split them up and create more purpose-built applications to fit with what the user wants. Newspeak centerward make easy newapplications indeed.

I’ve just pushed a new application as an example use of the KDE PIM Platform called coisceim, which is used for managing trips.

Using coisceim I can now associate a mail folder, calendar of todo items, and kjots book with an event, and track it as one semantic object, a trip. The video below shows the current UI (which obviously needs work:) ) being used to create a trip, mark todo items as done, and edit notes.

(MP4 version)

Coiscéim, pronouced ‘Kush-came’, is an Irish word meaning footstep. I dropped the fada from the application name out of sympathy for those non-Gaelgoir gearheads.

Coisceim provides a single user interface for accessing mails, todo items and notes relevant to an event. In my day job I do some travel for consultancy and to deliver Qt trainings. The planning of such events usually includes emails back and forth about the content and time of the training and flight, car and hotel bookings. Alongside that, the training manager creates todo items which must be completed prior to the training such as printing the material, getting in touch with the customer etc. We handle those in KOrganizer (until now). Additionally, I need to make notes about who to contact when I arrive, the address of the hostel etc, and during the training I use notes to keep track of student queries so I can answer them the following day. A single focussed, coherent application for all of those aspects is intended to make this all easier to manage.

Interesting new user stories emerge with purpose-built applications on the new platform, such as being able to use a dedicated Plasma activity for planning a trip. In the video below I use a Plasma activity which is configured with a KJots plasmoid to edit a note which is already part of a trip planning. The plasmoid is used as a form of well organized clipboard in this case.

(MP4 version)

Because no application owns the data and there can be many applications capable of accessing the same data, editing the notes in one application updates them in all applications instantly. So when I edit the note in the KJots plasmoid, the note in coisceim is also updated.

Coisceim can also of course be embedded into Kontact, and there is a mobile variant using some components from the Kontact Touch suite.

(MP4 version)

In the KDE PIM community we have many ideas about other task-orientated applications we’d like to build, but we’d like to hear other ideas too. The ideas worked demonstrated at the last KDE PIM meeting like notetaker are also good examples of the kinds of directions we can go with PIM data visualization.

Writing coisceim, including the Kontact plugin and the mobile variant has taken a total of approximately 5 man-days. It is clearly not a complete application yet, but most people would appreciate that being able to turn an idea into a screencastable prototype in one week is certainly impressive and a credit to the platform. Further work on the application might involve making contacts part of the UI, using Nepomuk to automatically create associations of emails todos and notes to trips, make it prettier etc, but I don’t know if I’ll ever have time to do that. As a platform dude I’m more of an enabler really. I just made the app to show what the KDE PIM Platform is capable of, so if anyone else wants to take the reigns I’ll happily mentor.

What tasks do you do which cause you to switch between many PIM applications at the same time? What keeps you tied to the cloud (if you don’t like that :)) ?


Get every new post delivered to your Inbox.