Mono 2.6 + MonoDevelop 2.2 on openSUSE 11.2

Fantastic news — Mono 2.6 and MonoDevelop 2.2 are out! Be sure to read the detailed Mono 2.6 release notes.

If you are running openSUSE 11.2, it’s quite simple to safely update your entire Mono stack and stay up to date with any 2.6 updates:

  • zypper ar -f -n Mono repo-mono
  • zypper mr -p 10 repo-mono
  • zypper refresh
  • zypper dup -r repo-mono

Those instructions will change the Mono distribution from openSUSE to the upstream Mono repositories.

I highly recommend installing MonoDevelop 2.2 (zypper in monodevelop), though if you already had it installed, the above will update you to the 2.2 release.

MonoDevelop 2.2 Integrated Debugger
Integrated Mono 2.6 soft debugger in MonoDevelop 2.2

A huge congratulations and thank you to the Mono team for another exceptional major Mono milestone!

UPDATE: apparently there is a problem on the x86_64 build in the openSUSE Build Service. This appears to be an OBS bug, but for this reason, it’s recommended that you use the repositories at

Exciting updates on the road to Banshee 2.0

At the Gran Canaria Desktop Summit last week I demoed my new work-in-progress Netbook-focused interface to Banshee called Cubano.

Cubano: Experimental new Banshee Interface

Cubano is designed with the Netbook in mind, but is certainly not limited to such a device. I prefer this clean and simple interface to the more traditional Banshee interface already, even on my desktop. Cubano is more about experiencing your music than managing it.

I am aiming to introduce visual metadata (photos, colors) and simple whitespace as UI elements to separate and emphasize content instead of the hard lines from traditional toolkit widgets.

However, even with a minimal interface you don’t lose any of the power to which you may be accustomed from the traditional Banshee interface.

Cubano: Experimental new Banshee Interface

I must stress that not all of the UI concepts here are solidified or indeed implemented. A few quick things to note about what will change in the very near future:

  • The painful source combo box will go away, don’t worry! It was just a widget that already existed in Banshee that I was able to easily reuse to connect the dots.
  • We’re working on a grid view for artists and albums.
  • I don’t care for the header either — it will receive much attention in due time.

Feel free to checkout Cubano’s source code, but you’ll also need clutter, clutter-gtk, and clutter-sharp from Clutter git master, and Banshee from GNOME git master. Bleeding edge!

Lastly, let me further stress that Cubano does not replace Banshee as we know it today. It only augments it. Cubano simply provides a different user experience on top of the existing Banshee platform.

Platform you say?

Trendy, I know. Banshee is in its third generation now. It’s been designed to be completely extensible, and major components are abstracted and organized in reusable ways.

As such we’ve fostered the development of many Mono/.NET libraries, most of which are not specific to Banshee and can easily be reused in other projects.

We essentially glue everything together with Mono.Addins, and build user interfaces on top of it all. What this means is the traditional user interface we’re used to in Banshee is an astonishingly small 875 lines of C# code.

Therefore, it’s conceivable, and even quite easy to think of Banshee as not just an application, but a platform for building new applications and user experiences. Ergo, Cubano.

A quick overview of the Banshee platform building blocks

For those interested in some of the wider details of the design and utility behind Banshee as platform, I recently had lovely a discussion on the topic with Scott Hanselman — Senior Program Manager in the Developer Division at Microsoft — for his podcast, Hanselminutes.


A major take-away from this platform discussion at GCDS last week is talk of re-basing the core of F-Spot — the wonderful photo management application — on top of Banshee itself.

The goal is simply to allow F-Spot to benefit from Banshee’s mature and maintained core, which provides many of the underpinning necessities in F-Spot, and allow the F-Spot developers to focus on the more interesting task of organizing and manipulating Photos.

While nothing is set in stone, I have a simple proposal:

  1. Re-base F-Spot’s non-UI core on Banshee’s non-UI core.
  2. Implement basic photo importing, tagging, and viewing as a Banshee extension (an optional feature). This would mean showing photos in Banshee like we do for videos.
  3. With Banshee/Cubano supporting basic photo management, grow the F-Spot user interface and experience to be more like that of professional tools such as Adobe Lightroom — an experience missing today on the Linux desktop.

GCDS Slides

The talk I gave at GCDS covered the above and a bit more. The slides are available here, but may be a bit terse if you weren’t in the audience. I’m not sure if my talk was recorded or not.

Nevertheless, for your perusal:

Slides from GCDS 2009 talk

openSUSE 11.1 on Linode ala zypper dup

I’ve been a Linode user for around four years now, and have always run Debian, until today. Last year Linode added openSUSE 11.0 as one of the distributions available to install, and I tried it very soon after it was available. Unfortunately it could barely boot (UML related issues I assume), and without any time to poke around, I switched back to my Debian image.

This weekend I decided to try again, even though the openSUSE version from Linode is still 11.0. I figured, “I’ve never actually done a [so called] dist-upgrade in openSUSE, so maybe I should try.” I was quite impressed.

It took all of about 30 minutes to fully migrate my Debian Linode to openSUSE 11.1 – with fully working/migrated lighttpd, mysql, and git-daemon.

  • Deploy an openSUSE 11.0 distribution in your Linode, boot it.
  • Log in as root (via SSH, not LISH)
  • Nuke the 11.0 repository list: /etc/zypp/repos.d
  • Add the 11.1 base repository: zypper ar -f openSUSE-11.1
  • Update the update stack: zypper in zypper
  • Refresh the repo (probably not actually necessary, will be done automatically by the next step): zypper refresh
  • Update to openSUSE 11.1: zypper dup

At this point you will have fully migrated from openSUSE 11.0 to openSUSE 11.1, something that historically has been very difficult with SUSE. zypper is awesome! Now reboot the machine as a sanity check, and configure for updates.

  • Add the update repository: zypper ar -f openSUSE-11.1-Updates
  • Patch the 11.1 install to be fully up-to-date: zypper up

Reboot again as another sanity check. At this point you have the latest patched and stable openSUSE 11.1 on your Linode. The openSUSE base install is fairly stripped down by Linode, so I recommend installing and setting up the firewall (SuSEfirewall2), sudo, iputils, lighttpd, mysql, git-daemon, etc.

Additionally, you can easily update to the latest stable Mono release by subscribing to the official Mono OBS repository:

  • zypper ar -f Mono
  • zypper in mono-core mono-data mono-data-sqlite mono-web

So finally I am still a happy Linode user, but now with my favorite and most familiar distribution, openSUSE! I’m looking forward to playing with ASP.NET MVC on Mono 2.4. Any good MVC blog engines out there?

Droid Fonts for openSUSE

openSUSE Logo

Just a quick note that I have packaged the Droid fonts from Android for openSUSE. I’ve submitted the package to Factory so we should have them in 11.2. Droid fonts are freely available from Ascender.

Install ’em now!

Stefano Forenza has some more details on getting the most out of these delicious free fonts. Kudos!

Update: I incorrectly attributed Stefano’s post to Neil J Patel, who actually pointed out Stefano’s post on Twitter. Twitter is king! So thanks to both Stefano, and Neil for spreading the link :-)

Mono 2.0 wins developer product of the year award!

Congratulations to the Mono project for winning the Product of the Year Award in the .NET Tool/Add-in category!

"It is no surprise to see Rich Internet Applications (RIAs) take the prize for technology of the year; however, seeing the open source project Mono 2.0 grab the honors for .NET tool is a surprise," stated Bradley Jones, Senior Executive Editor of’s Developer Channel.

Very exciting!

Announcing Moonshine, the project never formerly known as Pornilus

For the last month, I have been working on a new project officially called Moonshine, but referred to as “Pornilus” in some affluent circles.

Moonshine is a project based on Moonlight that leverages the built-in Windows Media capabilities of Silverlight to bring Windows Media playback to Linux in a fully legitimate way, without forcing the end user worry about what a codec is. This is possible because Microsoft provides the codecs directly to all Moonlight users, regardless of their choice of Linux distribution.

Very simply, Moonshine:

  • Allows an end user to experience Windows Media content on the web.
  • Brings Windows Media playback capabilities to a user’s desktop for playing local/arbitrarily downloaded content.

Moonshine powering HBO and C-SPAN

Install Moonshine

Of course you’ll also need Moonlight installed. If you don’t have the
proper version installed, the Moonshine page will tell you.


On the Moonshine page, there is an XPI available to install for Firefox. You must have the latest Moonlight installed and Firefox 3.0 or newer. The Firefox shell that provides local media playback however is not part of the XPI. You must build Moonshine from source to have this feature. Packages will soon be available for openSUSE, and hopefully for other distributions soon.

Additionally, you must disable the Totem GMP/Windows Media plugin in Firefox, since it basically tells Firefox it can handle the same Windows Media mime types, even if the codec is not installed for GStreamer. It would be really great if Totem would only advertise mime types that GStreamer actually supports on a given user’s system.

Moonshine Overview

The project consists of three components:

  • A media player written in Silverlight/JavaScript that stands on its own.
  • A Firefox/NPAPI plugin written in C that claims support for Windows Media mime types and enables embedded playback of Windows Media on the web.
  • A Desktop Application that allows local playback of Windows Media content, implemented in JavaScript as a XUL overlay that re-purposes Firefox’s user interface to be more appropriate to media playback instead of web browsing.

If you do not care about the really technical details of Moonshine, I’d advise you to stop reading now, and just install Moonshine and try it out! If you’re interested in the details of my life over the last month, read on!

The Silverlight Application

The actual media player for Moonshine is implemented in Silverlight/JavaScript using my MTK widget library. MTK uses the basic approach in GTK for widgetry. Many of the base concepts are similar: size requisitioning, allocation, parenting, realization, etc. To write the Moonshine player, I basically implemented GObject, GtkWindow, GtkWidget, GtkContainer, GtkBox, GtkHBox, GtkVBox, GtkButton, GtkLabel, and GtkScale, hastily of course.

MTK even supports a small level of native look-and-feel integration by reading system/theme colors from the browser’s CSS mapping.

It was still a really entertaining hack: MtkObject for example contains a simple virtual method and event implementation, which greatly simplified writing widgets. JavaScript purists who know better than I will probably bash this though, screaming something about “but think of the prototypes!”

All this effort was necessary as unfortunately Silverlight 1.0 (which Moonlight currently targets) does not offer a toolkit – it really is just a glorified canvas/stage. When Moonlight 2.0 is released, the MTK side of Moonshine will go away, though it would be very interesting to re-target MTK from XAML to say, SVG. I would love to see someone try that, it should be relatively straightforward.

What’s interesting about the Silverlight player is that it works as an entirely standalone Silverlight application, suitable for embedding on any web page. Of course though my JavaScript is very specific to Firefox 3.0+ I assume, so that kills a little value there. Patches welcome.

The Firefox Plugin

Finally, Moonshine provides an NPAPI plugin that advertises it supports Windows Media to Firefox. When Firefox comes across said media, it loads the Moonshine plugin. Moonshine in turn loads Moonlight, and proxies NPAPI calls directly to Moonlight. Moonshine then injects the Silverlight JavaScript into the browser, and binds it to the Moonlight plugin instance. From the browser perspective, it’s Windows Media, but the real stuff under the hood is just pure unadulterated Moonlight, driving a standard Silverlight application.

Additionally, a further piece of JavaScript is bound to the plugin object that emulates pieces of the standard Windows Media ActiveX/object API for further compatibility.

The implementation details on the Moonshine plugin are a bit interesting:

  • Moonshine provides the 4 standard NPAPI entry points: NP_Initialize, NP_Shutdown, NP_GetValue, and NP_GetMIMEDescription. It proxies each of these calls, excepting NP_GetMIMEDescription to Moonlight’s own NPAPI entry points.

  • Inside of NP_Initialize, Moonshine calls Moonlight’s NP_Intialize, and then overrides three NPP functions to be returned to the browser: NPP_New, NPP_StreamAsFile, and NPP_Destroy.

  • The NPP_StreamAsFile override simply prevents Moonlight from receiving that call, which would cause Moonlight to try to load WM content as XAML. The NPP_Destroy override just allows Moonshine to clean up its Moonlight binding on an instance, and then call’s Moonlight’s version of the function.

  • And finally, the juicy NPP_New override actually creates its own NPP_New call against Moonlight. All it sends to Moonlight is the width, height, and HTML DOM ID of the requested WM player, and sets the onload and source attributes on Moonlight to appropriate values for binding to the injected XAML/JavaScript player.

So this all means that Moonlight has absolutely no idea that the content its driving wasn’t hard coded in the web page. For all Moonlight is concerned, Moonshine is the browser. Plugins helping plugins, that’s what it’s all about.

And it all started as an extension

Moonshine was a really annoying project at first, and it took a while to come together. Most of the real progress and code that ultimately became Moonshine was written over the last two weeks.

Originally I wanted to avoid writing an NPAPI plugin and instead opted for writing a Firefox extension. What a mistake. I have learned way too much about Firefox and the Mozilla platform. It’s huge. But I must say, it was actually pretty pleasant to work with. Most APIs are pretty well documented. MDC is your friend, but a checkout of the Firefox source code is your better friend.

The mistake isn’t really the fault of the Mozilla platform, but a misunderstanding on my part of what I really needed to accomplish. My original version listened to the DOM, listened for new streams, etc. to intercept Windows Media mime types. This finally was working fairly well, but really was just a giant hack. I could not stomach the abuse I was causing inside the browser, and in no way was comfortable with releasing it.

However, the final nail in the extension approach was when I encountered web sites that actually check the plugin registry for a Windows Media plugin, and do not even create DOM content I could bind to if no plugin exists (ahh, gotta love the web). And of course the only way I could find to actually modify this registry was to be an NPAPI plugin.

So I threw away all of that code… about 1000 lines of JavaScript replaced with about a 1000 lines of C, an impressive trade-off — all things considered.

Going Forward, Looking Back

It’s been a very interesting few weeks, but I am so tired of working on this. I am aching to get back to Banshee. I do however want to make this work on the Mac under Microsoft’s own Silverlight. Or maybe someone out there can do it for me? It would be a fun hack!

Additionally, I am pretty interested in MTK, but can’t afford to work on it. I would be absolutely thrilled if someone would rebase the code on top of SVG. SVG needs a toolkit! It’s pretty pointless to continue working on MTK if it just targets XAML, since Silverlight 2.0 provides a toolkit. Any SVG/HTML5/Canvas enthusiasts out there are more than welcome to the MTK code. Keep me posted!

UPDATE: Last night I fixed a bug in Moonshine that prevented Moonlight from downloading the Windows Media codecs if you were running in plugin mode. If you experienced a “Bad address” error, please install the 0.2 XPI.

A couple of ideas for contributing to Banshee

Jono’s blog post about Banshee Kickin’ it has some interesting comments that I’d like to address, specifically regarding the new track editor and Internet Radio in the recently released Banshee 1.4.

The Track Editor

The new track editor is fully extensible. This means you can add your own pages to the dialog and get full first class editing support. All of the current pages are implemented in the exact same way you would need to write an extension page.

What I would like to see are a few pages contributed at least initially by the community:

  • Creative Commons metadata/license support
    A lot of work on this in the past had been done in the past, but never to a quality or completeness I was comfortable with for including in core. This support could either be an extension page to the editor, or an extension that interacts with existing pages/fields, like the copyright field.

    Additionally, the extension could make a track column and query field available, so you could easily search for and view Creative Commons music. This was a pain to do in legacy Banshee, but it’s a few lines of code in 1.x.

  • Music Brainz
    A page that allows for figuring out missing metadata, and also submitting track information back to MusicBrainz. Maybe it could also generate PUIDs. We have a complete C# implementation of the MusicBrainz web API (no native library needed) thanks to Scott Peterson, and it’s used in other areas in Banshee. This really should not be that complicated to do.

I wrote a quick example today on how to extend the track editor. The example implements a History Page which allows you to change the play count, skip count, and last played date to arbitrary values. More could be done here, and in fact I’d like to make this a core page anyway.

Banshee History Extension to the Track Editor

  • Download the example
  • Extract, change directories, and make run
  • Play with the code!
  • You need Banshee 1.4 and Mono 1.9 or better (I opted to use C# 3.0 in the example)

Internet Radio

We made a decision early on in the 1.x series to provide very strong Last.FM support. We’re fairly resource constrained, so this meant making traditional Internet Radio something of a second class citizen. In fact, I made a choice to not ship any default radio stations because really I should not be the one picking stations, and so many of them fall offline in the life cycle of a distribution iteration that supporting this is silly.

However, I made sure all the underlying pieces for good Internet Radio support were in place. We have a station editor, stream metadata is reflected in the UI so when playing a stream you can see “track changes” which in turn can trigger cover art, and the RadioTrackInfo object even handles fetching and parsing of remote station playlsits. We support M3U, PLS, ASX, and XSPF formats, and possibly some others I am forgetting.

The Radio source that ships by default is a bit bare in terms of UI, but this was intentional. You can add new stations and manage them, but we really need something like StreamTuner or Shoutcast, like Jono says, that builds on the Internet Radio core features. Implementing new sources is fairly straightforward. You can even extend the existing Radio source to build on it.

Implementing this would be a great standalone extension that I would love to ultimately roll back into core, maybe for 1.6 if an enthusiastic contributor steps up to the plate.

So what are you waiting for?

Join the community of enthusiastic Banshee contributors and write something great today. We have a large and functional API, lots of features to build on, and everything is designed around extensibility.

Such a large API can be daunting to learn, yes, but Banshee is also organized very well. We also have API documentation for Monodoc, and probably the best way to learn about Banshee’s internals is to just read the source to the extensions we ship in core. All the great features in Banshee are just extensions!

Lastly, don’t hesitate to stop by on the IRC channel asking for help!

Banshee 1.4 hits the streets, packed with Awesome

The Banshee logo

After three months of hard work on feature additions, a slew of bug fixes, stability and performance improvements, and a small tangent on porting to Mac OS X, we have released Banshee 1.4 — the new stable series!

HTC G1/Android Support Out-of-the-box

Banshee Device Overview

Got a G1? Get a Banshee! Banshee is the first media player to offer a customized experience for the Android/G1 phone.

G1 Purchased Music Source

  • Synchronize or manually manage your media collection on your G1 phone
  • Cover art is fully supported on the G1
  • Import music you purchased through the Amazon MP3 store on the G1 in one quick pass

Additionally, if you try to delete music you purchased on the Amazon MP3 store without actually being in the special “Purchased Music” source, Banshee will not comply. This prevents accidental deletion of music you may not yet have backed up to your desktop computer. To remove purchased music from the device, do so from the “Purchased Music” source.

With the G1 + Banshee, an experience similar to what iPhone users enjoy is available.

Amazon MP3 Store + G1 + Banshee

A final note on the G1 support: because the Android platform is open source, I was able to easily figure out optimal ways of implementing Android/G1 support. For instance, I was unsure what the maximum cover art size should be on the device, so I just read the source. It was a nice for once to not have to reverse engineer or guess!

Banshee on Mac OS X

I wrote a bit about this already, but 1.4 ushers in a new era for Banshee! From now on, Banshee will always be officially released and maintained for Mac OS X, 10.4 and newer currently.

Banshee 1.4 on Mac OS X 10.5

Because this is the first release of Banshee on Mac OS X, we are calling it a beta quality technology preview. This means that there are some known stability issues, and certainly some missing features, but it’s good enough that we really encourage people to start trying it and filing bugs.

Some of the missing features for OS X (also known as “places where we are eagerly looking for new contributors”):

  • Hardware Backend
    Without a backend implementing interfaces in the Banshee.Hardware namespace, the OS X release does not feature any device support (no audio CDs, no digital audio players, no CD burning). For ambitious developers familiar with hardware APIs in OS X, following the HAL backend for Linux/FreeBSD is a great place to start!

  • Embedded Video
    Currently the Quartz video backend in GStreamer does not implement GstXOverlay. Work needs to be done to make this happen (even though obviously Quartz is not X11), or specific embedding can be done in Banshee itself. I’d prefer to see native GstXOverlay support however.

  • Screensaver/Power Management Inhibit
    In GNOME, this is implemented to prevent the system from sleeping or starting the screensaver when Banshee is in full screen mode (i.e. playing a movie).

  • Support for the Front Row/Apple TV remote
    This would just be a fun thing to write. Someone step up!

Finally, I have to give Eoin Hennessy a huge thanks for his work here again. Also to thank are the Songbird guys who have invested in making GStreamer usable on the Mac. We are looking forward to contributing in this space and working with Songbird, now that we are off the ground. What they have accomplished here is no small feat, not to be overlooked!

New API for customized mass storage device support

Implementing G1 support was done through the newly extensible mass storage device extension. That’s right, extensions extending extensions. With this new API, it is now possible to add “polished” support for certain classes of mass storage media players, like the G1 or BlackBerry devices.

For instance, here’s how the G1 is implemented:

Since this is just another Mono.Addin extension, new device support like this can be added outside of Banshee itself. I should note that this augments the portable_audio_player HAL specification. It’s to be used when more than the generic mass storage functionality is desired for a device.

The Release Notes Speak

For a more in-depth overview of what Banshee 1.4 has to offer, please read the release notes. Here’s a quick overview on what they cover:

  • Media player devices now support playlists (iPod, MTP/PlaysForSure included)
  • You can now have your device automatically sync with your library, or continue to manage it manually
  • I’ve implemented a brand new track editor that is fully extensible. It’s very easy to add new pages!
  • Shiny new UI for now playing makes for a more entertaining “background” or “party” mode
  • There’s now a tool that can rescan your library, adding new items or removing stale ones
  • File names/paths can now be automatically updated when metadata changes
  • Lots of minor UI improvements and polish
  • Stability and performance improvements

Try it already!

Banshee 1.4 is hands-down the best Banshee ever! Period! Packages should be available soon for your favorite Linux distribution, if they are not already (openSUSE and Ubuntu packages are at least ready now). And of course we have a shiny new Mac OS X .dmg!


Update: Ryan wrote a great article about 1.4 over at Ars Technica. The comments are interesting. Is there anyone out there who has tried running Banshee on OpenSolaris? It works on FreeBSD…

This post powered by the “Similar to Eric Clapton” Last.FM radio station in Banshee 1.4.

Digg It!

Cross Platform thoughts through the lense of Banshee

Banshee running on OS X 10.5
Banshee 1.3.2 on Mac OS X 10.5

A huge amount of thanks goes to Eoin Hennessy for all of his efforts to bring Banshee to the Mac. Eoin singlehandedly fixed cross platform bugs in our core, worked out some kinks in the build, and implemented a Mac OS X platform backend to provide tight integration with the OS (i.e. the menu bar).

So how do I get it?

On Friday we will release Banshee 1.3.3, the last preview/developer release before we officially bless 1.4 as the new stable series in a couple of weeks.

As Miguel mentioned, we will be releasing for the Mac from here on. That means that along side our source code tarballs, RPMs for openSUSE, and packages published through other distributions, we will have a .dmg available to download.

If you are courageous, you can try to build Banshee on OS X today. However, our trunk does not yet run. Eoin has done all of his work in github, and while this branch runs, it’s slightly outdated, and does not use the new build environment I wrote this weekend.

Eoin is in the process of extracting patches that we will merge this week into trunk. These patches include the fixes to core, and the OS X integration.

Banshee running on OS X 10.5
More bling, before I ramble on about technical things and get teary-eyed and nostalgic

How does this cross platform stuff work?

Banshee is designed in a very modular way. We have a fairly small core, which is completely platform agnostic. It uses only ECMA/OSP .NET APIs and APIs of libraries which are themselves cross platform and open source (Mono.Addins, NDesk.DBus, Cairo, GTK, etc).

Additionally, all real features are designed as extensions: the Play Queue, video playback, the notification area, Last.FM, and so on. This means that we can easily pick and choose features by adding or removing assemblies from a package.

Finally, anything requiring a platform specific implementation is abstracted into an agnostic factory/interface, and implementations are loaded as extensions.

Cross platform frameworks give you the 90%, but it’s really the 10% that matters

It’s virtually impossible to write a cross platform application that does not suck if you just stick to what a single framework provides. By this I mean if we used only features in .NET or if a Java application used only features in the Java framework, the user experience would feel isolated and sandboxed.

  • In GNOME this means using GConf to store settings and working with DBus services like GNOME Settings Daemon. We interact with the screensaver, we support multimedia keys, integrate with Brasero for CD burning, and so on.

  • In the general UNIX world (Linux and BSD/OS X), we have a POSIX IO backend that performs much better than the System.IO .NET backend.

  • In Linux we have the HAL hardware backend (which I like to think of as HALAL, but don’t read too far into that).

  • On OS X we integrate with the dock and the system menu bar.

Okay, but what about Windows?

Ah, right. Windows. There’s one tiny little drawback to making a media player written in C# cross platform. Namely, we require GStreamer on all three platforms, and in turn we have a small library, libbanshee, written in C. Of course this pain is more than eased by the incredible power and functionality that GStreamer offers.

The truth is, I know next to nothing about Windows, and I find it incredibly frustrating to work in that environment. I am getting close however to getting a build of libbanshee on Windows. With this piece in place, we’ll be able to release on WIndows.

Currently the goal is that we’ll always distribute libbanshee as a binary on Windows, but the rest of Banshee can be built using “F5” in Visual Studio. This will be very interesting as it opens up Banshee to a whole new world of contributors.

Google Chrome has seen an incredible amount of contribution from external contributors simply because the source can be downloaded, opened with Visual Studio, and compiled. Users can tweak some code, and immediately see the results. This is where we want to be – Linux, Mac, and Windows.

The End Result

What is important with all of this cross platform work is simple: infiltrate the proprietary platforms, attract users and developers to free software, and grow the open source ecosystem. Ultimately, we’d like to think this will help Linux adoption. Applications are the key, not the platforms.

Banshee on Mac OS X is symbolic to me. It marks a period in our project where we step out of the realm of our comfortable and lovable GNOME community and into different communities, creating and bridging through the shared goal of open and free software. Users unite!

Finally, I’d again like to thank Eoin for his great efforts with our code, Imendio for their great work on GTK for OS X, the Mono team for the solid 2.0 release, and the GStreamer community for the best multimedia framework an application developer could ask for.