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

Comments

List of XUL Applications?

[AKAImBatman]

SongBird just goes to show what XUL can really do. Most people shun it with a, "Coding serious applications in JavaScript? Yeah, right." But with the XPCOM Standard Library as a foundation, the XUL platform is really a great way to build applications. (There's a really cool application here that shows off XUL's abilities.)

XULRunner is still a problem, though. It's not clear to most programmers that XUL applications can function just as well standing alone as in a browser. Songbird is a great start, but does anyone know if there's a list of existing XULRunner applications? If such a list existed, it would be a lot easier to show people what XUL can do just by pointing them to a single URL.

Re:List of XUL Applications?

[PoprocksCk]

Well for starters, Firefox, Seamonkey and Thunderbird will be able to run on top of XULRunner soon. That'll be especially nice for us Linux folks who prefer shared libraries over having multiple copies of the same duplicated libraries installed on our systems.

Re:List of XUL Applications?

[Anonymous Coward]

Most people shun it with a, "Coding serious applications in JavaScript? Yeah, right."

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.

Re:List of XUL Applications?

[AKAImBatman]

What an impassioned rant! With all the energy and time you put into it, I really feel sorry that's it's so incredibly wrong. :(

because the entire interface is implemented using Gecko, the widgets aren't native.

As it so happens, the widgets are native. Mozilla exposes the underlying implementation. Which is why buttons look like Windows, Mac, or GTK+ buttons. The caveat to this is that you can create XUL buttons/components that are entirely virtual. These components are generally used to produce skins like that used in Firefox. But most XUL applications actually rely on the native components instead. Which is why the Amazon browser I linked to looks like a native Windows app.

JavaScript is an interpretted language. And it's slllllllow.

It's also just glue. All the heavy lifting is done by the XPCOM components, which are FAAAAAASSSST.

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.

Putting aside for a moment that this is an issue in all GUI programming, Mozilla does support multithreading. It just doesn't do it at the Javascript level. Threads are pushed down to the XPCom level instead, where they do the most good. (e.g. The XmlHttpRequest object can run synchronously or asynchronously.) If you really must multithread your JavaScript app, then cooperative multithreading is easy to do. Timed call-backs allow you to regain control whenever you need it, or in spurts if you'll be processing for a long period of time.

Re:List of XUL Applications?

[generic-man]

Open Safari on Mac OS X 10.4. Start VoiceOver (CMD+F5 or CMD+FN+F5 on a laptop). Notice how virtually every UI control has enough metadata to let Mac OS X know what it is.

Open Firefox (or Camino). Start VoiceOver. Notice how absolutely nothing in the web page display area is interpreted as a Cocoa widget. Notice how in the web page display area, checkboxes, drop-downs, text fields, and any other controls lack any access to Cocoa services such as spell checking and Dictionary. The same lack of OS-native widgets is apparent in Firefox for Windows, though GTK does a much better job of emulating the look of these widgets, if not the feel.

If it looks like a native app, it's not necessarily a native app.

would be cool if...

[professorhojo]

It would be cool if you could send instant messages to the people whose libraries you can browse. Internet cafes would be forever changed.

Re:would be cool if...

[Rob T Firefly]

Didn't the original Napster or Kazaa have a feature like this? As I recall, all it got me was the occasional request from a stranger to "pls share more (random artist, possibly one I wasn't even sharing) pls kthx."

awesome!

[Anonymous Coward]

we can finally play music on our pcs!

What's that quote?

[Lord Ender]

A caged source can't sing?

Songbird is barely usable

[Anonymous Coward]

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

Re:Songbird is barely usable

[Z0mb1eman]

downloading from petshopboys.com will freeze songbird.

That's a feature.

bugs, questions etc etc

[xsst4]

if you guy's are having any bugs or anything just file them at bugzilla.songbirdnest.com and if you guy's have any questions or just want to idle be sure to connect your clients to irc.landoleet.org and join us in #songbird. Thanks have a good one! --Inc

What's the big deal?

[Brix Braxton]

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.

Re:What's the big deal?

[r0bl0rd]

Check this screencast: http://songbirdnest.com/screencast/ and try to do that in Winamp, MusicMatch, WMP, etc. =)

best, r0b

Re:What's the big deal?

[aymanh]

Erm, I think you are missing the point, Songbird is a stand-alone music player, some of its key features that give it special interest here are:

• Written in XUL and JavaScript.
• Runs on top of Mozilla's XULRunner platform.
• Cross-platform, can run on Linux, Windows, and Mac OS X (among the others).

It can be seen as a proof of concept on how general purpose multi-platform applications can be developed on top of XULRunner. Songbird also lets you visit online music stores and organize your music library, which makes it an Open Source alternative to iTunes.

Enough to deserve /.'s interest I guess.

Re:What's the big deal?

[Stealth Dave]

so what's new about any of this?

This one goes to eleven

Re:What's the big deal?

[j1mc]

While I wouldn't get too excited about being able to just search the web through a browser within a media-player, I think that there's more to Songbird than just that.

On the Linux front, Songbird will give us a media player with an attractive front end, all of the standard rip-organize-burn capabilities, plus the ability to purchase music from online music stores. Not to knock the current Linux offerings (I'm currently an Amarok user), but the UI's aren't as attractive as Songbird's UI (yes, XMMS is slick-looking, but those buttons are so small . . . ), and AFAIK, the ability to buy music from online music stores through a Linux app is slim to none.

As for iTunes and Windows Media Player, they each lock you into their own music stores (the iTunes Music Store and the MTV-powered Urge, respectively). Songbird is going to allow you to purchase music from a wider array of online music stores from the outset, and online music stores will be able to write plugins to make them searchable from within Songbird. From the website . . . "Web page authors will be able to publish playlists and transfer MP3s into Songbird to build digital music stores like eMusic, music subscription services like Yahoo! Music Unlimited, virtual jamming services like Ninjam, playlist sharing services like WebJay and more."

And, of course, neither iTunes nor WMP plays natively under Linux. All in all, a strong cross-platform app like this just makes Linux that much more viable for everyday desktop users.

songbird?

[Lachryma]

Oh right, the music player with the farting bird logo.

Re:songbird?

[LiquidCoooled]

If you think the original logo was bad, take a look at the songbird bugzilla page.

THey have the logo with cramps, the runs and throwing up.

lovely.

Doesn't play anything on Mac OS X

[RustNeverSleeps]

Too bad it reports that all songs are 1:22 seconds long and won't play them in OS X.

Why XUL?

[kahei]

Is XUL a good application platform? If so, why?

It doesn't seem to have much to reccommend it at first glance -- a language that lacks features and performance (javascript) a runtime that's bulky (mozilla), and worst of all a real case of Java-itis -- XML files and source files that endlessly have to be kept in sync and bundled together, no self-documentation and no metadata.

I ask because I tried porting a semi-complicated IE plugin to XUL and had to give up -- admittedly, I had to give up because of limitations in the HTML renderer, but long before then I had learned to dread the process of hooking into Mozilla at all. And that's saying something, considering that the original IE plugin was entirely made of hand-written COM, written against IE's none-too-predictable interfaces.

So, why XUL? I appreciate that you _could_ write an application in it, but what's the unique selling point that justifies all the work?

Re:Why XUL?

[kahei]

To be honest, your reply comes across as 'don't use XUL'. Being cross-platform (to platforms that have Mozilla available and installed) is hardly a big unique selling point that justifies a whole new way of doing things. As you point out:


To be sure, you don't need to do XUL- you can do the application in Qt, GTK+, Fltk, and a few others and get
the same results with less effort unless you need some HTML rendering support
...and even if I do need HTML rendering support, I can embed a browser or launch a browser or use an HTML control, or use Java or (on a good day with the wind blowing S by SE) Mono or Ruby+[binding].

So, why use XUL...

Re:Why XUL?

[bcmm]

Is XUL a good application platform? If so, why?

There are other cross-platform systems, but none which integrate as well with the system's look. The browser component is nicely integrated. It's very easy to use HTML + CSS to render interface components.

It doesn't seem to have much to reccommend it at first glance -- a language that lacks features and performance (javascript) a runtime that's bulky (mozilla), and worst of all a real case of Java-itis -- XML files and source files that endlessly have to be kept in sync and bundled together, no self-documentation and no metadata.

It isn't written in Java. Javascript isn't even anything to do with Java. Also, it doesn't run inside Mozilla or even require Mozilla to be installed. I haven't looked at the code, but poor commenting and source management isn't an issue with the language.

I ask because I tried porting a semi-complicated IE plugin to XUL and had to give up -- admittedly, I had to give up because of limitations in the HTML renderer, but long before then I had learned to dread the process of hooking into Mozilla at all. And that's saying something, considering that the original IE plugin was entirely made of hand-written COM, written against IE's none-too-predictable interfaces.

Why is it a good idea to try and "port" something like that? Neither the interface nor the language have anything in common, and in any case you just said the code you were trying to follow wasn't very nice anyway. XUL doesn't even work in a similar way to COM. That sort of thing calls for a rewrite from scratch.

So, why XUL? I appreciate that you _could_ write an application in it, but what's the unique selling point that justifies all the work?

You could I suppose... At least some of the Mozilla suite, Firefox, Thunderbird and Nvu are pretty nice applications, don't you think?

Curious about the 'variety of online music stores'

[thatguywhoiam]

Surely Songbird doesn't support DRM-wrapped content? (Not that this is their fault at all, even remotely).

(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.)

Open Source Media Player?

[dbc001]

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

Re:Open Source Media Player?

[WoLpH]

I use MPD with QMPDClient, there are probably some visualisations available aswell but personally I don't use them.

I also use Amarok, altough it does have visualisations build in, I can't call it really lightweight.

Re:linux

[Kethinov]

Quoth the main page:

Songbird is open source, will run on Windows, Mac OS X and Linux and supports user contributed, cross-platform extensions.

The DRM question

[Kadin2048]

Yeah I was kinda wondering about how they're going to manage the whole DRM business.

It sounds like it will support DRM-ed music stores (they mention Yahoo's subscription service, I think); how they're going to accomplish this I'm not sure of. I can only assume that each service will have its own binary blob for parsing and playing back its own files, and then the interface will pass commands to these blobs?

Still seems like it would be easy to get around: if the DRM parts are compartmentalized, how hard would it be to lie to them? For example, let's say you have a subscription-music service that makes all your music expire after a certain date if it doesn't get a 'keep alive' reset command. Couldn't you just keep passing it the wrong date? (This is a trivial example, I'm sure that the system would pull its time off the internet from an authenticated, trusted server, but it seems like there could be other attacks that would take this form.)

And if the music player software actually has access to the decrypted audio stream that the blob produces (for example, if it has a graphic equalizer, or visualizer), then it's pretty trivial to make the software do conversion as well. I can only imagine that even if you asked people not to implement such features, they would be in such demand that people would put them in and distribute modded versions regardless. (And, if it's GPL OSS, you can't really do anything about this.)

I don't see how the DRM components could possibly be open source. As I think we all know, DRM relies fundamentally on obscurity: you can't build "open source DRM," because then you just make the inevitable reverse-engineering happen more quickly. And I don't think you can have a subscription music service without DRM (unless it's like eMusic's, where you get a certain number of downloads per month). I guess what I mean is that you can't have an "all you can eat" subscription service without DRM, at least that I can imagine.

Re:The DRM question

[Myen]

Even more fun - their actual audio playing stuff is XPCOMized VLC, used under GPL2.