XMMS2

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 ... [More] 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 [Less]

XMMS2 got the good news again! It feels awesome, not only because we get to participate in this fantastic program once again, but also the prospect of going to a mentor summit later this year is awesome :-) Thanks Leslie, you know we love you! ;)But ... [More] , I heard someone whispering that our proposed projects was less interesting this year! Let's do something about that! Do you have a good idea? File it at our wiki, TODAY! :-) [Less]

Good news! We have been accepted into this 2009's Google Summer of Code! Head over to the GSoC page at Google and apply as mentors / students.

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 ... [More] clear!I think the official XMMS2 client should be written in the Qt toolkit and these are my reasons for it: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.The Qt API is very clean and easy to use.You can write Qt applications in C , Python or Ruby (see my language discussion further down).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.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! [Less]

As I said earlier, what’s lacking to make an awesome XMMS2 GUI client is a common vision. We need a dream! I have a dream that one day this community will rise up and live out the true meaning of its creed: “when the music is end xmms power of the ... [More] pc.” I have a dream that one day on #xmms2, the sons of former GTK developers and the sons of former Qt developers will be able to work together on the code of a GUI client. I have a dream that one day even the state of Microsoft, a state sweltering with the heat of instability, sweltering with the heat of dull interfaces, will be transformed into an oasis of freedom and music. I have a dream that XMMS2 clients will one day live in a community where they will not be judged by their GUI toolkit but by the content of their user experience. I have a dream today! (Kudos to Martin Luther King for the original draft.) In the end, all we want is an awesome music player. But do we all share the same definition of what an awesome music player is? Probably not. In fact, I don’t think most of us even knows what an awesome music player is; if there were one, we wouldn’t have to build one, right? So the goal here is to gather qualities that we expect of such a project, and refine them into a common vision. I won’t start dropping design mockups or fancy feature ideas until we have established what we all want, conceptually. What I expect of this GUI client, and the vision for the project, is that it should be: Exciting Original Expandable Clearly focused Nobody wants to work on boring project — at least nobody in the FOSS community. Elsewhere, people do code for money and dream of larger cars and larger breasts, but in the XMMS2 community, all we dream of are exciting coding projects. It should be exciting enough to make developers drop their own projects to work on it, and to make users fret about it. It should be exciting enough to compensate compromises by the quality of the end result. One way to make it exciting is to make sure it is original. It’s way more thriving to build something new and unique than to try to replicate something everyone has seen before. Harder, yes, but more exciting! For the users, it will also help it stand apart from the variety of existing music players, either as a grand fiasco, or as a sexy newcomer. Because people love to experiment and to make things their own, it should be expandable: rather than a static monolith, it should let developers and users play with it and customize it and adapt it to their needs. There will always be limits of course, but to remain true to the XMMS2 spirit, we should favor a modular design and bundle freedom inside. Finally, it is primordial to establish a clear focus on what problem this client is meant to solve. The worst usability often comes from a blurry focus, or the wish to solve too many (or all) different problems. I will come back to the first three qualities in future posts, and elaborate on the clear focus in the rest of this post. Before anything else, we need to define what we want the target audience to be: newbies? your mum? the average random user? hardcore music fans? “everyone”? It’s a tough call, but clearly, by trying to content everyone, we couldn’t provide the best solution for each group of users. But if we look at the XMMS2 demographics and, more importantly, the (brand new) Vision, it’s easy to see that we already target a particular niche of music listeners: demanding audiophiles, passionate fans who care about music. Which is very different from “everyone” or an average user. Concretely, they might tend to have larger music libraries and more complete releases than scattered tracks. They might be more keen on browsing and organizing their music (using tags, folders, or their own semantics), on fine-tuning their audio setup (soundcard, equalizer, gapless playback), on joining music networks (e.g. Last.Fm) and discovering new music. They are the people who spend multiple nights getting complicated plugins and fancy themes working in foobar2000, to provide a full experience for their music; not the people who gaze in wonder at the atrocious WMP fullscreen visualization. We can expect slightly more patience and curiosity from them but in return, we must provide them with powerful tools, with a great user experience and ways to make it their own. Now, it doesn’t mean that the player should be unusable by anybody outside that niche. Simply, it should focus on filling it as best as possible, before anything else. Therefore, my suggestion is to make this XMMS2 GUI client a great music player for people who care about and love music, and make it a rich experience for playing, browsing, searching, organizing, discovering and enjoying music. It is an ambitious goal, but I believe it is one that is exciting, original and expandable! Pearl, by Camila… Addendum: FLACvest just posted a very flattering post about XMMS2 and mentions similar attributes that would benefit XMMS2: Totally Fresh and Unique, Beautiful, Cross-Platform, some “magic” ingredient! [Less]

So this post is totally non-technical.The last month I have been on a new diet. The reason for this is that I realized that I was simply getting way over-weight and unhealthy, so I decided to try something that worked good for my mother. I haven't ... [More] blogged about this before because it's not something fun to talk about. But now, after four weeks on the diet and increased physical activities I have lost 14 kilos (about 30 pounds) and I am starting to feel light, full of energy and a lot more healthy.I have also decided to participate in midnattsloppet this year. It's a 10 km run throughout Göteborg in the end of August. Want to join? :) [Less]

I am on vacation this week, we where supposed to be in Sälen the whole week for some skiing, but due to some mandatory classes that Lisa had to attend, that didn't happen. We will leave for Sälen today instead and get 3 days in the slopes, that will ... [More] be perfectly fine as well, I am actually looking forward to it a lot.Also two days of vacation at home haven't been unwelcome at all. I have had time to reinstall my Eee 901, this time with easy peasy. I like it a lot, it really makes the most of the small screen and I didn't have to worry about drivers and X11 configuration etc, etc.I have also submitted XMMS2 GSoC 2009 application. With some great help of theefer and wanders we finialized all the texts and got it sent away. I have a good feeling about this year, I am more motivated to be the admin and we have learned a lot. I just hope that Google gives us the chance this year as well.On a XMMS2 releated note DrM has finaly entered testing period. This is waay overdue and we hope that we can wrap it up before the start of the GSoC, so that students can work against that version and not some unreleased one. [Less]

We have just applied for Google Summer of Code 2009. Hopefully we will be included in the program for the fourth year in a row. Get involved in our ideas and community now! See our GSoC 2009 portal here!

Episode 2 was a lot better! Actually, I suspect that this was the episode that they where aiming for showing as the Pilot from the beginning. It explains a lot of the backstory and is less "ordinary" than the first episode. I just miss the trademarked whedon humor, please give!

I think it’s a great thing for people to finally be stepping up to think of a way forward for XMMS2, especially after a period of relative stagnation. However, I have a few bones to pick with the current shape of things. Given the direction that the ... [More] ‘XMMS2 Vision’ is taking, I I’ll say this: I think software freedom is overrated. We’re in 2009, an era where Open Source is practically mainstream - computer manufacturers such as Dell and ASUS are selling desktop and laptop computers with Linux (typically Ubuntu, or some other Debian derivative) pre-installed. ASUS’s Linux-powered eee PC helped launch the netbook revolution, with many observing that the netbook was an ideal application of the low cost benefits of a Linux-based OS. After a decade of people wishing to see Linux as a relatively mainstream desktop OS, it is practically there - any moderately computer literate average Joe can easily grab an Ubuntu Live CD and be on his way. That’s not to say that freedom is not important, but simply chanting ‘freedom, freedom, freedom’ does not build a thriving community of passionate users. Well, actually, it does, but that’s a kind of community that borders on blind faith, religious dogma and rabid zealotry when it comes to ‘freedom’ - e.g. the cult of GNU. Passionate, indeed, but is this what you see for the future of the XMMS2 project? When I think about the XMMS2 project, I tend to take the ‘freedom’ aspect for granted, given that XMMS2 has been an open source project for most of its time in existence. It’s a given that XMMS2 is released under an open source licence, and that the small community of loyal developers, users and other fans has been built upon this foundation - I don’t think that is likely to change. When looking for a future vision for the XMMS2 project, I’d say that it would be more useful to search for more practical goals than to get lost in navel gazing about freedom. In the end, what people care about is code that works. I recognise that putting together this vision is a good opportunity to examine the values that are important to the XMMS2 project. More importantly, however, I think what’s needed is a sharper focus on achieving certain goals. Without a drive towards such goals, we’re pretty much left where we currently are, simply nibbling at ideas that we think are good at the time, without making much progress towards something more coherent. I’d like to present my own vision for XMMS2 - by no means a definitive attempt, but merely my opinion - and comment on what has been said/written so far. First of all: XMMS2, what is it? We use the term ‘XMMS2’ in many contexts, with multiple meanings. I feel that, without a clear idea of how to define the term, we’re likely to be left floundering, especially since this is at the very core of what we’re trying to do. XMMS2 is many things: A music player. (Or ‘audio’ player? We’ll get back to this..) A framework for building custom ‘jukeboxes’? A community of people who study, use, develop or otherwise contribute to a common codebase. A project - to produce a music player - encompassing the community effort. Personally, over the years I’ve been involved with XMMS2, it has been all this and more: An opportunity to participate in an Open Source project and understand what it’s about - especially the ability to do so from firsthand experience rather than being an outsider looking in. An opportunity to put my software development skills into practice - and learn more about development in multiple languages, algorithms, software development processes. An opportunity to discover more interesting kinds of music than I knew of - music that’s almost non-existent on local radio stations and music shops. An opportunity to virtually meet and interact with strange people from all over the globe. When I was first introduced to the XMMS2 project, I was merely a university student tinkering with something I found interesting at the time. What I learned from the subsequent experience, however, tremendously increased my development skills and practical knowledge of how software can be developed. I can say with some amount of gratefulness that being involved with the XMMS2 project is one of the major things that has shaped my career as a software developer so far - what I learned from Anders’ engineering skills is still something that has an influence on how I build software today. Perhaps, then, one might consider ‘education’ as one of the values of the XMMS2 project. Indeed, XMMS2 has been a mentoring organisation in Google’s Summer of Code program for a number of years now - something which I believe has been quite instructive for both the students and the mentors involved. I’d like to think that there are others who might be interested in learning a thing or two about ‘real’ software development to join the community. Granted that code produced by the XMMS2 project is far from perfect, and far from being an academic example of great software engineering, I believe that there is much one can learn by being involved in the community and studying the code. (And no, the XMMS2 project isn’t unique in this respect - many other open source projects also fit the bill) Beyond what XMMS2 means to each community member, we need to look at where the project is headed. The way I see it, there are two main points to make about this: 1) building the code (or system, or framework - technical excellence), and 2) building the community (community excellence). In this process, we must bear in mind that we’re trying to appeal to certain relatively distinct groups of people: Users Developers Both groups view technical and community excellence differently. In general, as far as users are concerned, if the product works, they’re (mostly) happy. (If they’re really happy, they might even tell their friends) As far as community is concerned, users are happy to occasionally rely on the community for support when things go wrong (Why can’t I play my music, etc). A user’s experience in both respects will dictate how long the user will remain loyal. For example, if XMMS2 can’t easily play a particular file, the user will seek an alternative solution and likely switch to a different player. If the user cannot get the community to resolve a particular problem, or finds the community relatively unfriendly, he will likely gravitate towards a more friendly community. As far as developers are concerned, technical excellence is about producing interesting code in particular ways - a more efficient algorithm, a more flexible plugin system, a library with a clean API, a seriously cool feature that’s not available anywhere else. The cornerstone, however, is the existing developer community around the project - these existing developers are the gatekeepers to the existing codebase, the ones with inside-out knowledge of how the existing system works, the ones who share the history of the project and dictate where it is going. The interface between contributing developers and core developers is exactly where the value of ‘open source’ comes into play. On one hand, contributing developers are attracted by how easy it is for them to modify existing code to introduce new features or fix defects, and on the other hand, core developers must have processes in place to ensure that code of relatively high quality is accepted - while encouraging the better contributors to remain interested. Somewhere in the middle, there’s an intersection between the set of users and the set of developers. This typically takes the form of passionate users with certain skills moving towards becoming developers by contributing code to the project. In general, I think that this should be encouraged, as it grows the base of community members available to support users and induct new developers. OK, so I’ve talked a bit about what I think is important for XMMS2 as a community. I’ll post some more later about users, developers and XMMS2 as the product. [Less]