El Tramo | Qt

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.

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.

Mixing Cocoa and Qt

2008-08-16T00:00:00+02:00

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. To create our auto-updating application, we first lay down the auto-updater interface in a (pure) virtual class:

class AutoUpdater {
  public:
    virtual void checkForUpdates() = 0;
};

The Sparkle implementation of this interface has the following C++ header:

class SparkleAutoUpdater : public AutoUpdater {
  public:
    SparkleAutoUpdater(const QString& url);
    ~SparkleAutoUpdater();
    virtual void checkForUpdates();
  private:
    class Private;
    Private* d;
};

Note that I am using the Pimpl idiom to hide Cocoa-specific internals from the API into a private internal class. The actual impementation of the SparkleUpdater needs to call Sparkle's Objective-C API. However, we cannot write the implementation in Objective-C, since the header for our updater (which will be included from within our application) is written in C++. Luckily, GCC's Objective-C++ extension allows you to mix Objective-C with C++ without any problem. So, we create an Objective-C++ implementation of our updater, and put it in a .mm file:

class SparkleAutoUpdater::Private {
  public:
    SUUpdater* updater;
};

SparkleAutoUpdater::SparkleAutoUpdater(const QString& aUrl) {
  d = new Private;
  d->updater = [[SUUpdater sharedUpdater] retain];
  NSURL* url = [NSURL URLWithString:
      [NSString stringWithUTF8String: aUrl.toUtf8().data()]];
  [d->updater setFeedURL: url];
}

SparkleAutoUpdater::~SparkleAutoUpdater() {
  [d->updater release];
  delete d;
}

void SparkleAutoUpdater::checkForUpdates() {
  [d->updater checkForUpdatesInBackground];
}

All we do here is create an SUUpdater (Sparkle's updater class), set it up, and activate it in our checkForUpdates() method. To integrate Objective-C++ classes into a Qt project, qmake provides the OBJECTIVE_SOURCES variable. Knowing this, we add our new classes to our qmake project file:

HEADERS += AutoUpdater.h
SOURCES += AutoUpdater.cpp
mac {
  HEADERS += SparkleAutoUpdater.h
  OBJECTIVE_SOURCES += SparkleAutoUpdater.mm
  LIBS += -framework Sparkle
}

Before we integrate the updater into our application, there is still one detail we have to take care of: if you write Objective-C code that creates objects, you need to instantiate an NSAutoReleasePool to enable Cocoa's memory management. Although we could do this in SparkleAutoUpdater, we're going to put this in a separate initializer class, so we can share this with other Objective-C++ implementations in our application. The body of this class looks as follows:

class CocoaInitializer::Private {
  public:
    NSAutoreleasePool* autoReleasePool;
};

CocoaInitializer::CocoaInitializer() {
  d = new CocoaInitializer::Private();
  NSApplicationLoad();
  d->autoReleasePool = [[NSAutoreleasePool alloc] init];
}

CocoaInitializer::~CocoaInitializer() {
  [d->autoReleasePool release];
  delete d;
}

Now all that's left to do is integrate all this into our application:

int main(int argc, char* argv[]) {
  ...
  AutoUpdater* updater = 0;
#ifdef Q_WS_MAC
  CocoaInitializer cocoaInitiarizer;
  updater = new SparkleUpdater("http://el-tramo.be/myapp/appcast.xml");
#endif
  ...
  if (updater) {
    updater->checkForUpdates();
  }
  ...
}

That's it! If you want to try this out yourself, just download the sources of this mini-project, build them, and off you go. Don't forget to remove ~/Library/Preferences/be.el-tramo.mixing-cocoa-and-qt.plist to clear Sparkle's state cache.