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!
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
February 13, 2009 at 01:41
You can try to make a plugin for Songbird that can use xmms2 as a backend. Songbird can be great GUI client indeed.
February 19, 2009 at 03:07
I would write my own kick-butt client, but alas, the Java bindings are no where to be found (and I’m too lazy to learn a different language).
*hint hint* :)
March 13, 2009 at 04:48
Hey, afrol of Konfetka here.
Sorry, BatteryCell and I haven’t been developing very actively for several reasons:
*School and work have hit us hard over the past year,
but more constructively, you mentioned an “awesome framework we have in place to create a great music player”.
That’s certainly true, but when I left there were some point that made development of a C++ GUI hard as hell:
*Collections problems. A lot of detailed applications require the GUI client to keep a copy of the collection to crawl it over and over. I remember we had loads of problems getting the data, and no one but you would even consider talking to us about it for real (thank you personally for that!).
*Everything keeps changing! Service clients are a great idea! However, so many things should be implemented as service clients with a modular interface that for a GUI it’s simpler to rewrite most of the interface. We had to rewrite a backend when collections were dropped on us :-). It is hard to develop and intuitive and awesome GUI to a changing API.
I understand XMMS2 is in deep development with many awesome ideas, as the website clearly states, but that is also, I would argue, the main reason that no GUI “can really be called polished, mature or attractive enough to motivate people to switch.”
Beyond that, I suppose there were some community issues at hand for us. Mainly, over visualization.
March 16, 2009 at 16:43
While LXDE’s LXMusic isn’t SUPER SHINY, it is quite servicable, being somewhere between the FUNctionality of Xfmpc and Sonata.
What I like to do is dump my entire music collection into it, which the SQLite database handles quite well, to my surprise, less constant RAM usage than with MPD/(+any+MPC+goes+here)…
I leave it configured to be always on in the tray with an icon… which you then just click to show/hide the interface.
Then you utilize the search box depending on your interest/mood, and ba-da-bing!
Like I said, it’s minimal UI wise, but I think its definitely serviceable. Hopefully it will continue to be a nice combo: XMMS2/LXMusic on Xfce.
As for already polished clients, I suppose some of the MPC’s could be subverted with a backend for XMMS2… I would definitely consider recruiting some folks to subvert Sonata or Xfmpc, which are really quite nice at what they do…
Just a suggestion.
BTW, I’m glad I’ve given XMMS2/LXMusic a try! I like what I see in the way of potential, and with the eq.py script/client in 31-band EQ mode it certainly makes a nice combo for my rather picky ears and minimal UI tastes.
Best in Any Manner Of Things…
March 16, 2009 at 16:51
Josh Rickmar: Java API can be found at http://telharmonium.devjavu.com/
March 16, 2009 at 16:53
@Josh: There are new Java bindings, have a look here:
http://telharmonium.devjavu.com/
@afrol: We’re keen on fixing that collections problem, even Eclipser/Zharf mentioned it recently. Hopefully should be part of our work on DrN, as we also work on wrapping the xmmsv_t in the bindings.
And yes, we are a moving target, I guess we’re lacking more pressure to stabilize the API as there isn’t a strong client and user base yet. Hopefully will change with the next releases (we tried to break everything for this release, DrM, so as to minimize the future changes).
@FLACvest: thanks for the support. We hope to run a Summer of Code project to complete the MPD-bridge to welcome more MPD users in the future.
One of our goal is to have a minimal resource footprint while still offering enough features to be a strong music player. The choice of interface depends on the user, but we hope to start building a new client that will give a new incentive to use XMMS2 and show all its possibilities!
March 22, 2009 at 19:45
Oh wow, thanks for pointing out the new Java bindings. I’ll definitely take a look at them!
November 2, 2009 at 21:37
I think it would be very important to define the actual user needs, it should be the basis for developers to start working on a usable interface.
How could this be achieved?
March 9, 2010 at 13:27
IMHO the reason xmms2 lacks good clients is that xmmsclient lib is just painfull to use. In fact in many it is easier to write a parser for some text format like MPD than to use the xmms client lib. Sorry…
March 9, 2010 at 13:34
s/In fact in many/In fact in many languages/
March 9, 2010 at 13:41
Is it because of the lack of good tutorials about how to use the bindings? Because I still believe they are very easy to use, you can do anything in just a few lines with much richer semantics than MPD (e.g. querying, listening to updates, etc).
March 9, 2010 at 17:27
Well… when I first looked at mpd I thought “wow, how easy it is to write a client”. When I first saw xmms2 the feeling was the opposite. (Though you are right about the rich semantics.)
The other problem is that everything breaks with every new release. Even the user has to juggle clients and servers versions to make them work together.