home

Git presentation at Purple Scout

On April 17, I was invited to do a presentation on Git for Purple Scout in Malmö, Sweden. Around 40 people showed up (including many XMMS2 folks) and endured 2-hours on what Git is, why it’s so awesome and all the fancy stuff you can do with it. I think people liked it and although most seemed to be using Git already, they were nice enough to say that they’d learned something anyway.

I’d given talks about Git previously in Switzerland, but for this occasion I reworked and pimped up my slides quite a bit to cover more material and have more cute diagrams. As before, you can get the slides for the Git presentation (PDF), or even fiddle with the source file, under the terms of the Creative Commons Attribution-Share Alike 2.5 License. Reuse, modify or poke fun at at will!

Sorry it’s still in proprietary Keynote format, because that’s the only vaguely acceptable software I found to make lots of diagram easily… Any Free alternative would be welcome, if someone knows of one.

It was great fun preparing and giving this course, and being back in Sweden and seeing friends again, so tusen tack till Purple Scout for making this happen!

Going beyond tracks and local data (Ep. VII: Return of the GUI)

Now that we have defined what/whose problem we’re trying to solve, and debated about the implementation details, it would be worth asking why a graphical XMMS2 client would be a good fit.

After all, we have a brand new korving CLI (nycli), isn’t that enough? In a sense it is, but it fills a different niche. GUI applications are good at things that CLI applications aren’t, and vice-versa. So the goal is to exploit the specific advantages of graphical music players.

For instance, even the most hardcore fans of the command-line will admit that the following tasks are easier with a graphical player:

Edit a playlist, using mouse selection and drag-and-drop.
Browse albums by cover.
Organize music manually into playlists or using dynamic collections.

But these are just simple examples that are now expected of any standard graphical music player.

Can’t we get something more exciting?

As Obama taught us, “yes, we can!”

Three main aspects usually poorly supported and under-exploited in music players are powerful tools to:

Browse
Organize
Explore/discover

Continue reading →

Gentlemen, start your toolkits (Ep. V: The Flamewar Strikes Back)

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.

Continue reading →

We need a dream (Ep. IV: A New Hope)

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 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

Continue reading →

XMMS2 GUI clients all sort of suck

Ask anyone on the street why they are not using XMMS2 right now and they will tell you the same thing:

But, like, all your GUI clients suck lol!

You needn’t have punched the poor guy in the face, because I also believe it is quite true.

We have quite a few clients (you will have to check out the matrix by yourself), but none that can really be called polished, mature or attractive enough to motivate people to switch. No disrespect to the authors (I’m even one of them), some cool stuff has been done, but graphical clients aren’t really “ready for the desktop” yet. Which is really a pity, given the awesome framework we have in place to create a great music player.

I believe that the reason for this isn’t that we don’t have competent developers, but rather that all of these projects are one- or two-men effort and not really thrived by the community. Because of the freedom you have to write your own client, well, people do: they follow their personal vision of what they want their music player to be like and start coding. Unfortunately, this isn’t the most effective strategy.

Perhaps thanks to the physicality of our meeting at FOSDEM, or to all the Belgium beer, we acknowledged that and decided that, now that the new official command-line interface (AKA nycli) has been merged and is being worked on by various people (thanks greafine, AnthonyG, nesciens!), it was time to get serious about a graphical client.

The best way to get people to work together on a new project is to establish a clear and common vision of what we’re aiming at, what are the ideas that structure the project, and get people excited about it! The vision should be compatible with the XMMS2 vision we’re currently discussing (thanks to Debian’s Bdale Garbee for the inspiration).

I want to make it clear that even if members of the XMMS2 community start working together on a common client, it is in no way incompatible with other people writing their own client if they so wish. Simply, we hope to gather people working on similar clients and focus the effort to build something really, really cool!

So I’m going to start posting things on this blog to propose directions for a vision to follow, and everyone is welcome to comment, reply, blog and debate the ideas so we solidify the basis we will start from. There will be a lot of things to discuss, from technical choices to interface challenges, so let’s get started!

Dance to the FOSDEM ‘09 beat

Over last weekend (February 6-8), I shared a fantastic time in Brussels with people from the XMMS2 team (and a few thousands over geeks and almost as many beers). We got together, mostly off our Google Summer of Code money, and spent some IRL time thinking of how to make XMMS2 better. Thanks to everyone who was involved, it’s been great fun!

Although tilman and DraX hacked fervently on GenIPC, most of what we worked on wasn’t code, but rather discussions on the organisation of the project, the status of projects waiting to be merged into the main tree (GenIPC, service clients, collections 2.0), as well as future projects we want to explore, such as mergestatus (a pimped up iteration of the merge page) and an official GUI (yes!).

The main issue we identified with organisation is the lack of clear vision of where we are heading. Projects like GenIPC or mergestatus are being worked on without a general and agreed upon (let alone written down) specification of all they entail. The decision we took was to try to get tru back into a role of project manager and require proper wiki pages to be written about all the major features that are being developed. I personally want to start blogging more about thoughts and projects I’m working on (I know I’ve said it before, but this time it is true).

Continue reading →