O’Reilly just sent us the cover for our upcoming XMPP Book, and it seems we got the world’s smallest ungulate: the lesser mouse-deer. I haven’t seen one in real life before, am not sure I ever want to, but still: great! Have a look below to see what the cover of the book will look like when it hits the stores in 2 months.

As much as I like CppUnit for writing C++ unit tests, I still prefer using Qt’s built-in QtTest module for Qt-based projects. This avoids a dependency on an external library, lowering the threshold for running and writing unit tests. Unfortunately, QtTest is very basic, and lacks some useful features such as automatic test registration and running multiple test suites in one test binary. In order to improve QtTest’s usability, I started creating some macros and classes that fill in some of the gaps, and bundled them into QtTestUtil.

Ever since I started using GMail as my mail client, I wanted to have an automatically synchronized local (off-line) copy of my GMail account. Such a copy would not only serve as a backup, but would also come in handy when I needed to consult messages when I’m without internet connection. It would also allow me to efficiently check my e-mail when I only have very limited (and expensive) bandwidth, or simply to find out which messages take up most space on my account.

With the arrival of IMAP support for GMail, it has become possible to efficiently synchronize your mailboxes, without having to jump through loops or downloading your whole history over POP3 every time you synchronize. While looking for an IMAP synchronization tool, I stumbled upon a post referring to mbsync, a tool which did exactly what I wanted. The post itself only talked about synchronizing your messages as a flat list, and did not talk about synchronizing labels. When trying to synchronizing all my mail, including labels, I bumped into some caveats of mbsync. Luckily, these problems can easily be fixed.

A while ago, the Psi development team switched from Darcs to Subversion for version control, because the Darcs pros (distributed, extremely simple and elegant) did not compensate for the cons any longer (slowness, non-scalability, ‘infinite’ merges, lack of community and tools, …). Our development was pretty central anyway at that time, so we decided that Subversion was good enough. However, we started to miss local commits more than we thought we would, and some of us are working on their own forks, which makes Subversion a suboptimal choice. We are therefore currently trying out Git as a replacement, which should bring us all the good stuff from Darcs, combined with the speed and portability of Subversion. Note that during the experiment, we will not be updating our Subversion branch any more (which will soon cause breakage, since Subversion automatically updates changes to the external Iris repository).

Qt does a great job at abstracting out platform-specific features into platform-independent C++ APIs. However, sometimes you still need to write platform-specific code for features that are not in Qt (e.g. to access the platform’s address book),  or to access platform-specific applications (e.g. iTunes) or libraries (e.g. Sparkle). On Mac OS X, almost all interfaces are offered through the Cocoa Objective-C interface, and the interfaces that are written in C++ have been deprecated and will disappear soon in favor of Cocoa. Although the language of Cocoa is different from Qt’s, Qt and GCC make it very easy to call these interfaces from within your application. In this post, I will show how this can be done by making an auto-updating application using Sparkle.

For a while now, I’ve been looking for a simple wiki to manage my personal notes and to do some basic shared editing. After looking through the vast number of wikis on WikiMatrix and still not finding what I was looking for, I ended up doing what hundreds have done before me: wrote my own wiki, and threw it on the pile of exitsing ones.

Although Psi has had a fair number of succesful Google Summer of Code projects so far, we have experienced some failures as well: the summer before last, 3 out of 6 projects didn’t make the final deadline. A project’s failure was typically due to not having anything really usable at the end of the summer, regardless of the good work that was done during the past months. To reduce the risk of such surprises, I decided to take an Agile Development approach for this year’s ‘Roster improvement’ project.