Slashdot Mirror
Songbird Source Released
Rinisari writes "The source for Songbird, a music-oriented XULRunner application, is now available via Subversion. Rob Lord, CEO of Pioneers of the Inevitable, released the source for the not-yet-0.2 version of the music player, which integrates a music library and the facility to purchase and download music from a variety of vendors. If you haven't heard of it, read the features list and try it out. Slashdot previously mentioned Songbird when it was released as a preview in February."
It would be cool if you could send instant messages to the people whose libraries you can browse. Internet cafes would be forever changed.
I am going to use this as a soapbox to vent about songbird. Before anyone jumps on me about songbird being in super super early stages of development.... I know. But I tried sb last time there was an article about how awesome it was. In theory it is a great application. Cool concept. In practice I found it barely functional. When visiting a webpage with links to audio content my machine would virtually freeze while songbird was parsing the content (for about 10-20 seconds). On top of that it didn't make much of a effort to give readable names to the files it would list. So I was left guessing what stationA3958afjdzak.pls was vs stationdkfkdjfd34242.pls.
Like I said I know its new and I look forward to it maturing some. But this isn't one of those alphas where the devs are just super dragging their feet till release (*cough gmail) This this really is ALPHA!
Trashhalo
A browser within a media player - I thought Winamp did that (and it was annoying to me) years ago. Musicmatch does it and WMP does it to - so what's new about any of this? I guess if you were a maker of Kiosks, this would be interesting but for the average user - any of the free existing software is just fine.
www.wildpad.com
(also, nitpick: did they have to make it look like iTunes so much? sheesh. As if these users need a superfriendly, superbasic user interface. XULRunner is innovative, but the app design, not so much.)
If Jesus wants me it knows where to find me.
While we're talking about media players, can somebody recommend a lightweight, open source media player for me? I'd really like to find one that has nice visualizations, FLAC support, support for streaming radio, and a decent id3 tag editor.
I'm still using winamp 2.72 because I've never found anything that compares (although Snackamp is pretty slick for dealing with my 20,000 song mp3 collection).
And for good reason! XUL is a terrible, terrible, terrible, terrible, terrible system.
Crap, now I have to back that up with reasons, don't I? And the fact that I hate JavaScript really doesn't count, does it?
You can think of XUL as being almost exactly like VB, except without any nice GUI tools for building UIs. Almost all the things people hate about VB also apply to XUL.
But anyway, that's rather vague. How about some specific reasons?
First off, XUL is rendered using the same rendering engine as Firefox uses for rendering webpages. Yes, when you're looking at Firefox, everything you see is rendered by Gecko. That includes the menu, the toolbars, the tabs, and the webpage itself. This mixing of UI and webpages is just asking for security holes. The webpage is embedded in what is practically an IFRAME within the XUL document. There have already been a number of security exploits caused by webpages elevating their privileges into the "chrome" security level. If ActiveX has taught us anything, there will likely be more.
This relates directly to the next problem: because the entire interface is implemented using Gecko, the widgets aren't native. They feel out of place. Gecko does an amazing job of making the widgets look almost-right, but they're still not native and they still don't look quite right, even on Windows (most work spent on this) and GTK (second most work). And forget about Mac OS X, it's not even close!
But the real problem with not using native widgets is that XUL doesn't get the benefit of a platform's accessibility features. Yes, they have some hacks that attempt to stitch XUL widgets back to a platform's native accessibility system, but this means that they're chasing whatever new features are added. Right click on a native text field on my Windows system, I get the full set of Unicode editing features for dealing with BIDI text. Right click on a Firefox text field, and it's not there.
And, finally, JavaScript. You knew it was coming. But I'm not going to go after the language, I'm going to complain about the JavaScript interpretor that Mozilla uses. Most of the widgets are implemented by using JavaScript glue to access native code using XPConnect. Some widgets are implemented almost entirely in JavaScript - this is why the progress meter under Windows looks completely wrong. The concept of having native code do the heavy lifting and using a scripting language to glue everything together is a very good idea.
But that turns out to be a problem. If you want to write a cross-platform XUL application, you can only use JavaScript since that's what XULRunner provides. (Keep in mind, if you want to run on every platform XULRunner runs on, it's JavaScript or else.) Otherwise you'll have to compile for every platform, and you can only rely on the core XPCOM objects to be available. JavaScript is an interpretted language. And it's slllllllow. And - here's the most important part - in Mozilla, it's strictly single-threaded.
Now, combine that up above with JavaScript being used to implement some widgets. Plus, the thread used to run chrome JavaScript is the UI thread - the thread that receives messages from the windowing system. This means that if an application is using JavaScript to do heavy lifting, the application will literally freeze while it can no longer accept messages. The windows will stop redrawing. Clicks will be ignored. Nothing will happen until the JavaScript finishes and the UI thread can start handling messages again.
Trying to write XUL applications that don't do things that are already implemented as part of the core XUL system is mostly a waste of time. XUL works best if you can write native code for the heavy lifting and use JavaScript soley for the UI. Unfortunately, that makes your application non-portable - something XUL is supposed to help solve.
All I have on my machine here is Winamp, Musicmatch, Sonique, ITunes, the POS Win media player, and probably some festering bits of RealPlayer that I haven't completely rooted out. I really need another player.
Some mornings it's hardly worth chewing through the restraints to get out of bed.
Considering your requested featureset, might I suggest Amarok ?