First of all, I used Sleek Migrate to retrieve the roster (and other) data from the server, and store it in the standard XEP-0227 format. I extended the tool a bit such that it supports Openfire’s User Import/Export format, a format generated by an Openfire plugin that is distributed with the server software by default. Using this format as input for Sleek Migrate avoids the need to create a user file manually. The changes I made to Sleek Migrate are currently available from my Git repository, awaiting to be pushed to the main repository.

I then wrote a short script that populates the Prosody data dir with the server data from the XEP-0227 XML file. Currently, the script only generates roster and account data, but adding vCard and Private XML Storage (used amongst others to store MUC bookmarks) should not be very hard. Until Prosody creates a native XEP-0227 importer, you can get the script from my Git repository.

QtTest’s recommended way to write unit tests is to compile and link one test suite per class separately, and using the QTEST_MAIN macro to generate a main() that runs this particular test suite. However, this introduces quite a bit of overhead in writing (creating a project file for every test/class), building (linking a binary for every test/class), and running (running a separate binary for every test/class, usually using a custom script) all unit tests. This overhead is especially painful in a project with many classes. All this conflicts with the general rule that both creating and running unit tests should be very efficient, and makes QtTest not well suited for unit testing as it is.

A first attempt at solving this problem is by manually creating a main() function that runs all tests. For example:

#include "MyFirstTest.h"
#include "MySecondTest.h"

int main(int argc, char* argv) {
  int result = 0;
  MyFirstTest test1;
  result |= QTest::qExec(&test1, argc, argv);
  MySecondTest test2;
  result |= QTest::qExec(&test2, argc, argv);
  return result;
}

The resulting binary runs all listed test suites. The downside of this approach is that you have to write quite a bit of boilerplate code: every test binary needs to have its own main() function that explicitly runs all the tests in that test suite, and which needs to be put in a file that has to include all the tests separately. In order remedy this, I took the idea from CppUnit to provide a macro which auto-registers a test suite, and makes it easy to run all registered test suites at once. Creating a test suite is now as simple as creating a .cpp file for every unit test, adding a call to
QTTESTUTIL_REGISTER_TEST to that file, and compiling that together with a shared main() that does nothing but call runTests() on the test registry. Since this main() does not explicitly depend on any test, QtTestUtil comes with a SimpleChecker.cpp containing this call, and which can be used by all unit test modules. As a result, no module needs to provide its own main() anymore.

An example of a unit test module using the macro and the shared checker described above can be found in the Example subdir of the QtTestUtil repository. It is worth noticing that these QtTest-based unit tests are more compact than the same unit test written in CppUnit (because the latter requires you to call a macro for every test in a fixture).

This is just a first set of utilities that QtTestUtil provides on top of QtTest. More utility classes and macros will be added as they are needed.

Up until recently, I’ve been using TipiWiki as my notebook, which is very light, simple, and easy to deploy. However, recently started running into its limitations, including limited markup possibilities (e.g. no multi-level lists), the lack of decent history (seeing who changed what, when), … I liked the idea of git-wiki, which used Git as its backend, giving it good history support, and the fact that all documents are in a real repository. However, git-wiki uses Sinatra, which requires way too much valuable resources than I want to spend on a simple wiki.

So, I took the idea of using Git as a backend, threw in the Textile PHP class for marking up text, and wrote WiGit: a simple, themable wiki in PHP (which is less cool, but also less heavy than Ruby/Sinatra), built upon Git, with history support, basic user support (from HTTP authentication), and pretty URLs. The default theme is still rough, and there are still a bunch of features coming up, but it should function properly already as a simple wiki for your everyday needs.

To add this package to your Fink tree, simply download both mp4box.info and mp4box.patch, and move these files to /sw/fink/dists/local/main/finkinfo. After this is done, you should be able to fink install mp4box. Because this package is not in the official repository, you will need to select `Retry using next mirror set “sourceforge” ‘ when Fink fails to download the package.

Note that this package isn’t ready for submitting to the main Fink repository yet for a couple of reasons:

• The GPAC configure script doesn’t allow to disable inclusion of external libraries statically. As such, it might be that GPAC links in libraries present on your system. This isn’t really a problem in practice, but should be resolved for clean builds.
• The MP4Box package file builds the GPAC library, and statically links the MP4Box binary against this. A better approach would be to provide a real package for the GPAC library, and add all the other utilities to this package as well.

LGMTray is implemented in C++, and only depends on libcurl (for opening secure connections to the GMail server),  LibXML2 (for parsing the GMail feed), and libxpm (for rendering the icons). It uses the FreeDesktop.org System Tray Specification to dock the application to the system tray, and uses Xlib directly for all the graphical functions (drawing the icons, communicating with the tray, …). It is currently very limited in features, but will probably evolve in the future (depending on personal and other people’s interest).

The goal of Greem is to be a clean, simple Qt/Qtopia client, built completely from scratch, using lessons learned from the Psi project. Since it is my intention to keep Greem as simple and clean as possible, some advanced features from Psi will not be available: multiple accounts, customizations that are only relevant to 1% of the population, … However, development will be focused on things that Psi also needs in the near future:

• Clean, unit testable APIs.
• New and improved roster (for meta-contacts, avatars, …)
• Server-side message archiving
• Reliable communication
• Simplicity

A lot of this will either flow directly back into Psi (which should be possible thanks to the decoupled APIs), or will be used as a guide to refactor certain parts of Psi that need it (e.g. the roster).

For the first release(s), not every part of Greem will be written from scratch, though. Although I already have a major part of the low-level XMPP server connection handling coded up, Greem will initially use Iris as its backend for connecting to a server. Anything beyond the connection (i.e. XMPP data structures, stanza handling, …) will be done outside of Iris. This way, the major focus can be on the front-end and general frameworks, without having to worry about the low-level implementation details (which can typically be a big hassle to get right). In the future, the Iris backend, which is connected through a very thin layer with the front-end, will be replaced by my own implementation of XMPP streams.

An update on the current status of the project will follow soon, together with some preliminary screenshots.

Since the script only is receiving minor tweaks and bugfixes lately, it is probably advisable to keep track of the Git development version from now on.

The only frustration I am left with is that not every webpage or software package that interests me has an RSS feed. I wrote AtoMail to have an RSS feed of projects (or webpages) that have mailinglists instead of RSS feeds. In addition to this script, I just released a script called SVNFeed, which I use to monitor Subversion activity of projects that don’t have an RSS-enabled Subversion Web interface. By monitoring the tags dir of a project, I can even get a more coarse grained granularity of updates, mostly up to the release.

Both scripts might be consolidated in the future, possibly together with even more RSS generation scripts I have lying around