Official XMMS2 client should be written in Qt!

I read the that theefer did the other day and I just wanted to voice out my opinion about the Official client. I don't doubt that all people in the XMMS2 community probably already know my position about this, but I wanted to make it perfectly clear!

I think the official XMMS2 client should be written in the Qt toolkit and these are my reasons for it:
  1. Qt works natively on all the platforms that XMMS2 runs on. More important, it actually looks good on all the platforms that XMMS2 runs on. It even looks good under GNOME these days.
  2. The Qt API is very clean and easy to use.
  3. You can write Qt applications in C++, Python or Ruby (see my language discussion further down).
  4. Qt bundles with QtScript, which is a ECMA compliant language, which means that we can extend the official client in QtScript. This means a very low entry-level for people that want to add functionality to our client. QtScript is (IMHO) not fast enough to be the sole language we should use, but that might change soon.
  5. Upcoming features like QtKientic will bring awesomeness to our client.

I also think that the base client should be written in C++, but supported by QtScript. First we had the idea that we should write the whole client in QtScript, just have a small C++ loader. I have researched this possibility but I don't think QtScript is ready for that. QtScript is slow, and you need the qtscriptbindings to bind the full Qt API to QtScript, that takes 2 hours to compile on my master macbook pro.

Writing the application in Python or Ruby would probably be more rapid than writing it in C++, but it will be a bigger pain to deploy. Qt/C++ is easiest to deploy because all the tools are already there and users don't have to install yet-another-lib. My second choice would be Python, mostly because I know Python, I don't know Ruby :)

How about xmmsclient bindings?
The last thing I would like to touch is about xmmsclient bindings. Right now I have Qt4 bindings that are native, that means that it doesn't use libxmmsclient beneath, they are not merged into the mainline, but could be found here. I think these bindings could be a good candidate to use in the client, but we would need to make it complete and merge it into XMMS2 first.

See this post as a material for discussion, I would love to hear your opinion. Let the flames rain!


Unknown said...

I don't understand the pain of python deployment?


End users will just download an .app, .exe, or aptitude install $theclient? Developers will issue some macports commands, I don't think we care much about Windows developers, and other developers just checkout the code and hack?

The time it takes to install python with macports on osx (you're one of the few developers on this platform right?) is far smaller than the increased development time caused by using C++.

If you want OS X users to continously try out your stuff then it's just as painful for them if it's C++. Either they have to install Apples development package and QT, or they download a pre-built .app, and if you provide pre-built .app, it's just as easy for the end users to use a python version instead. You could even setup a buildbot step that automates the production of selfcontaiined python-based .app's.

Tobias Rundström said...

My experience of PythonQt deployment comes from Kjell, but granted, this was ages ago. Maybe the process have been simplified.

I agree that writing stuff in Python would really cut development time so it's still a good alternative (which is why I put it in my post at all).

theefer said...

nano, have you actually read the second page? Development on OS X looks like a significant pain in the ass. ("PyQt is clearly unsuitable for building distributable Mac applications, and you're probably better off taking a more native approach for Mac ports.")

I don't know much more about working with the original C++ and QtScript, but given that those are supported by Nokia/Trolltech, I'd assume it's much more fluid.

OTOH I agree that a high-level language would be better for quick development, whichever it is.

Anonymous said...


Would you mind helping MusicBrainz streamline it's picard release process for OSX 10.3 through 10.5 and beyond? (The 10.3 - 10.5 part should infer the fact of Universal Binary-ness, of course.)