insomnia bytes

Note: tru just blogged about this subject, so I’m adapting my original draft and replying to tru’s post.

All graphical application projects face the dreaded perspective of endless flamewars about technical choices, and XMMS2 clients haven’t been spared:

What language to write the client in? What toolkit to use? What platform to support? Where to put the opening curly brace?

In fact, this freedom of choice seems to always have been one of the major obstacles to the creation of an official GUI client.

At FOSDEM ‘09, perhaps helped by the virtues of IRL discussions (and all the great food & beer), we had a debate about the pros and cons of all possible combinations and came up with a reasonable proposition that should hopefully suit most interested developers in the XMMS2 community.

Because we don’t want to require users to install unusual graphical toolkit libraries (good morning Rasterman), GTK+ and Qt are the only two obvious choices, with GTK+ having the slight advantage of being more widely installed in the GNU/Linux world. However, nobody really contests the claim that Qt is a superior API in terms of design.

One important argument brought into the discussion was platform support. In line with the XMMS2 Vision, we want to respect the users’ freedom to choose their OS by making the official GUI client run on a wide selection of systems, at least GNU/Linux, MacOS X and Windows. In the current state, GTK+ integration in MacOS X simply isn’t good enough, and given the new Qt licensing as fully Free Software, the Qt toolkit is the most appropriate choice.

The other touchy subject is obviously the programming language. Most people agreed that using high-level interpreted languages would make for a more dynamic and simple development process. The most popular contestants for the code throne are Python and Ruby, with Python more widely used and installed on GNU/Linux.

Either choice would require bundling the runtime with the client on proprietary platforms. A recent article on Ars Technica analyzed the deployment of PyQt apps on Windows and OS X, and while it seems reasonably good on Windows, the OS X support was quite lacking according to the author.

An alternative solution suggested by DraX was to develop the client QtScript, which is the ECMAScript (think JavaScript) implementation embedded in the newer Qt. It remains uncertain, however, how much can be done purely in QtScript and where are the limits, both in terms of performance and design limitations. tru hinted at it, but I think it’d still be worth investigating and experimenting before we draw final conclusions.

If QtScript was too limited, we’d have to rely on more C++ code (which is somewhat annoying for rapid development) or switch to Python (which isn’t particularly my language of preference, as some may know). In case of a draw, it might also simply be up to the people who start working on the project, including a potential Google Summer of Code student with XMMS2!

As tru suggested, it’d probably be best to use the native C++/Qt XMMS2 bindings, and stabilizing them could be part of the preparatory work for this project (and a good motivation).

In short, the current idea is to write the new XMMS2 client using Qt and C++/QtScript or possibly PyQt, and to have it available at least on the main desktop platforms (GNU/Linux, MacOS X, Windows). Discussions still open, but avoid feeding the trolls please.

Darth Vader on the violin, by Houston Marsh