El Tramo | Software

TwitCoop: A Desktop Cage for Twitter Mobile Web

2011-05-25T00:00:00+02:00

The official Twitter for Mac app gives a great interface for Twitter: lightweight, compact, no bloat, and it looks great. Unfortunately, amongst the hundreds of Twitter clients already existing, I couldn’t find anything similar for Linux or Windows. Instead of creating yet another client (which Twitter doesn’t like anyway), I did a bit of Qt WebKit coding, and created a small desktop client around the (current) Twitter Mobile Web interface.

Update: The mobile Twitter website was updated, and doesn’t work as well anymore with TwitCoop. I will try to upgrade TwitCoop to work with the new interface, but it is currently not clear whether this is at all possible.

First, some screenshots:

Features of this desktop interface include:

Compact
Provides an “official”, consistent Twitter interface
Automatically refreshes when new tweets are available (with a higher refresh rate than the default mobile web interface)
Opens external (i.e. non-Twitter) links in your preferred web browser
Allows you to hide the Tweet box, when screen real estate is a problem (e.g. on netbooks)
Allows you to customize the zoom level
Automatically logs you into your previous Twitter session on startup
Supports “kinetic scrolling”
Works on Windows and Linux

Note that some of these features may become obsolete once the new mobile interface becomes available to everyone, and maybe some stuff will break, so I will need to update this then. The mobile web application isn’t as responsive as a real native client, but this may change with the new mobile interface as well.

You can try it out for yourself by downloading the Windows version (requires the Microsoft Visual C++ 2008 Redistributable, which may already be installed on your system), or by building it yourself from the development repository.

Retjilp: A Native Auto-Retweet Bot

2011-01-09T00:00:00+01:00

Since I couldn’t find a bot that automatically retweets statuses using the native Twitter Retweet API (all I found was RSS pipes that prefixed messages with “RT”), I created one myself. Retjilp is a (Ruby) script that logs into Twitter, scans the statuses of the contacts you are following, and retweets the statuses matching specified words. The Swift Twitter feed shows the script in action, retweeting all Swift and XMPP related tags from the Swift developers. You can get Retjilp from the Git repository (or from GitHub).

Eclipse CPPUnit Error Parser

2010-08-24T00:00:00+02:00

I’ve recently been experimenting with using Eclipse CDT as IDE for Swift development. One of the handy things is that Eclipse CDT has support for parsing compiler error messages, allowing you to quickly navigate to the failing source code line by simply clicking on the error message. Although Eclipse CDT supports all the compilers we use for Swift out of the box, I was still missing the easy navigation for fixing failing CPPUnit tests. Since the error parser (just like almost everything else from Eclipse) is extensible, I wrote a small plugin for parsing CPPUnit error messages.

You can get the plugin by opening Eclipse’s Install new software menu, adding http://el-tramo.be/eclipse as a plugin repository, and selecting the ECPPUnit plugin from the list of available software.

Migrating from Openfire to Prosody

2009-07-03T00:00:00+02:00

Because Openfire has been hogging too much of my limited el-tramo.be server resources lately, and because I don’t need a beast of an XMPP server for only 2 users, I decided to replace it by the lightweight Prosody. The migration went flawless, with the help of two tools: Sleek Migrate, and a Prosody XEP-0227 Importer.

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.

Improving QtTest usability with QtTestUtil

2008-11-06T00:00:00+01:00

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.

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.

WiGit: A Simple Git-based Wiki

2008-07-21T00:00:00+02:00

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.

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.

MP4Box Fink Package

2008-01-03T00:00:00+01:00

I created a Fink package for MP4Box, the multimedia packager from the GPAC project. MP4Box can be used for manipulating (e.g. muxing, demuxing) multimedia files such as MP4, 3GP, AVI, MPG, TS, …

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: A Lightweight GMail Notifier

2007-10-19T00:00:00+02:00

I have been looking for a Linux system tray application to notify me of new mail on my GMail account. Unfortunately, all the notifiers I found either did not run on Linux, or had dependencies I was unable to meet on my machine (because I lack system administrator privileges). This is why I wrote LGMTray, a very basic GMail notifier, with very few dependencies.

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).

Introducing Greem

2007-10-14T00:00:00+02:00

After a short hiatus, I finally resumed work on my new Jabber/XMPP client project, which I christened `Greem'. The main goal of the project is to create a mobile Jabber/XMPP client for the Qtopia platform. The nice thing about Qtopia is that its target audience keeps on expanding: besides running on the GreenPhone (of which Trolltech was kind enough to provide me with one), Qtopia has recently been ported to the Neo 1973 (OpenMoko), and even Windows CE and Windows Mobile. In this post, I briefly describe what the expectations and the goals are for Greem, and how Psi fits into the picture.

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.

Qtopia Greenphone Grant

2007-08-15T00:00:00+02:00

A month or 2 ago, I applied for the Qtopia Greenphone Innovation Grant Program, an initiative from TrollTech to promote the development of applications for their Linux-based Qtopia Greenphone. I probably won’t surprise anyone by saying that I sent in a proposal about writing a good, cross-platform, mobile Jabber/XMPP client. Anyway, I was very excited to receive a mail from TrollTech yesterday, stating that my proposal was accepted by their review panel! As an applicant, I will be receiving a shiny new Greenphone, together with a Qtopia SDK to develop against. Deadline for submitting my application: October 31st. Let the coding begin.