Amarok Blog

No, I'm not announcing them, I'm explaining what is involved and why it's not just a matter of "throw up a zip file on a server".

Using things like kdelibs and ruby in Amarok is great: you get a lot of functionality that you don't need to develop yourself. On Linux someone else takes care of packaging it all up for you too, and since many programs use them, Amarok itself doesn't really pay the cost.

On Windows it's a bit different. From a quick test I did, a Visual Studio release build with the non-runtime stuff stripped away (debug libraries, linker files, header files, etc) comes out at around 270mb 200mb. Compressed with 7zip it's a more reasonable 70mb, but it's still a fair bit of data to be pushing around if we're going to be doing a reasonably frequent alpha and beta release schedule. A lot of that is stuff Amarok doesn't need (eg base KDE programs and graphics), but stripping that out becomes pretty tricky, and I'm not sure we'd want to.

The good news is Amarok by itself itself comes out to only 2.35mb compressed: so assuming that KDE on Windows reaches a stable(-ish) point in the near future, putting up builds of just Amarok itself will be quite reasonable.

Packaging it up is also an issue. If we use the kde windows installer builds, then it causes me two problems: firstly that the release schedule might not be convenient for Amarok, and secondly that the compilers it supports are mingw and Visual Studio 2005. I'm primarily using Visual Studio 2008, and so I can't compile against the binaries from the installer. In theory I could release mingw builds, but at this stage the Visual Studio builds are smaller, faster and (at least for Amarok) better tested.

On the other hand, doing manual packaging means that Amarok wont be in sync with the rest of the kde stuff and that could cause issues if people want to use other KDE programs. Nobody really wants to contend with kde on Windows having a separate distribution for each program.

At the moment Amarok isn't far enough along that it's worth dealing with these issues. I'd rather spend energy on making it worth using than dealing with packaging and installation nightmares. Yay for Linux where someone else deals with that crap for you!

Update:

Some of my figures were wrong, it's "only" about 200mb in total.

A breakdown of where the space is going (in kb)

12488 amarok
75559 kdebase
33109 kdelibs
5155 kdepimlibs
134 kdewin32
158 qimageblitz
42188 qt
16984 ruby
1354 soprano
1336 strigi
352 taglib
21283 win32libs

In theory, at least some of the qt, kdelibs and kdepimlibs, and most of kdebase can be trimmed, with varying degrees of pain. Getting it down to maybe 120mb installed and a 35mb download would probably be the limit of what is easily achieved. Of course, as mentioned above, then you'd be left with a half broken KDE install that would probably screw up any other KDE app you attempted to install. I know some people wont care about any KDE apps other than Amarok, but for those who do, to break them would be really bad form.

Update 2:

I've started a thread on the kde-windows mailing list to see if we can work out how we're going to handle packaging and releasing KDE apps on Windows. Hopefully we can work something out. As I mentioned, we have an downloader/installer/packager app already, but it needs more work before it's ready to handle non-developer use.

Unfortunately KDE on Windows is still a fairly small project, and it's a bit of a catch 22: need more people to push it towards release, need a release to get people interested and involved.

As far as download size goes, a lot of it is about perception. The first impression you get of an application is how big the download is. I don't want Amarok coming off as "bloatware". Although I may know that the download includes mostly KDE related stuff that isn't Amarok (heck, you get a file manager, web browser, etc), a new user wouldn't and would just think "this is even more bloated than iTunes". Perhaps the best way to do this is getting interest in other KDE apps on Windows, so people can see they're getting a package that lets them download and run a whole lot of useful stuff. Again, it's a pity we don't have the manpower at the moment to do it.

As some of you have probably already heard, Trolltech have committed their phonon backends to KDE's svn repository. Details here.

What this means for Amarok is we now have a proper audio backend for Windows (and Mac OS too). A proper phonon backend was one of the key things that needed to happen before Amarok on Windows could really go ahead, and Trolltech have delivered ahead of expectations.

For those few brave souls who compile amarok on Windows themselves, unfortunately the code in svn isn't fully integrated with KDE yet. I have a patch awaiting approval from the phonon guys that makes it work with MSVC, but mingw will need a little more work. Unfortunately Amarok will be audio-less on Windows until that happens (as I've removed the temporary backend).

Update (15/12): Amarok now uses this backend and can now play both local files and streams under Windows.

The views in this post are mine and are not necessarily those of the entire Amarok development team.

I suppose I should introduce myself, rather than just jumping in like I did with my first post about Amarok on Windows.

I'm Shane, I live in Brisbane and during the day I write engineering/scientific software in c#. Since that obviously means using Windows, and I like to listen to music while I work, that currently means no Amarok for me for most of my music listening.

So the reasons why I'm working on getting Amarok on Windows should be pretty obvious:

• I want to use what is the best music player. If I wasn't able to commit my changes to Amarok, I'd probably be working on it privately anyway. This way everyone gets to benefit.


• As a side benefit, I get to keep the part of my brain that stores all the useless knowledge about c++ active, given I don't use it much in my day job.


• I'm not doing it because of any great love of Windows. In fact, as a developer, Windows is somewhat unpleasant:
  
  
  
  • The command line is horrible, I find I keep a shell open to my linux machine for anything more complex than typing make.
  
  
  • The WIN32 API isn't what you'd come up with if you had a choice: not really Microsoft's developer's fault, rather just the accumulated weight of many years of backwards compatibility.
  
  
  • No source for anything, so if the documentation doesn't tell you what you need to know, it's all trial and error.
  
  
  
  

Anyway, onto the objections about Amarok on Windows. I thought I'd address the common ones I've heard here, so we can keep any flamewars in one post.

"There will be an influx of Winblows n00bs using Amarok"

Good for Amarok! If the find platform specific bugs, that's my problem to worry about (the other devs aren't going to waste their time fixing things on a platform they don't use). If they find general bugs or suggest new features, then that's helpful for everyone. And if it means Amarok gets more interest from people who want to help out because it runs on Windows, then that means more and better features for all platforms.

I see a wider audience as something to hope for, not fear.

"I don't want open source programs on non-open source operating systems."

The beauty of open source is that people can do things that people didn't originally intend. The drawback is that people can do things that people didn't originally intend. It's a double edged sword, and every change always ends up leaving some people unhappy. However, I think this has the potential to make more people happy than unhappy.

"I don't want the Linux version to get left behind."

Honestly, at the moment it's just one guy (ie me) working on Windows vs all the other devs working on the Linux version. Even getting the Windows version to the point where it does everything the Linux version can will be a great achievement (for example, I don't have an iPod so iPod support will have to wait until someone else helps out). There's no way the Windows version will ever become the focus. I'd rather spend my time adding useful features than writing platform specific code.

"If Amarok runs on Windows nobody will switch to Linux for it"

For the last decade or so people have been declaring it to be the year of the Linux desktop. The end result is (depending on who you ask) somewhere between 0.5% and 2% market share. This is despite the fact in that time we've gone from Slackware and fvwm being state of the art, to distros like Ubuntu which are easier to install than Windows, and both GNOME and KDE being wonderful desktop environments. To put it bluntly: people already aren't switching to Linux.

I'm not saying the fear is unreasonable. It gets the facts right but comes to the wrong conclusion. Apps are what really matter now: a decade ago, when Windows 95 crashed daily, and Mac OS didn't even have pre-emptive multi-tasking, Linux as an OS was light-years ahead technically and switching for the OS might have made sense. The field is a lot more equal now, and it's the apps that largely set things apart.

The problem is, most of the apps people want (or need) to run are on Windows. And switching all your apps at once with a switch of operating system isn't something most people are going to want to do. However, switching one app, say Winamp for Amarok, is something that people will consider. So one app here, one app there, and perhaps down the track everyone runs all cross-platform apps. If that's the case, suddenly switching OS doesn't seem so impossible.

Sure, it's far-fetched, but I don't think it's nearly as far-fetched as the idea people will switch OS for a media player. If you're a Linux fan, look at Amarok on Windows as building a bridge towards a future switch.