I’m going to the MonkeySpace Conference in Boston, yay!

I will be attending the MonkeySpace Conference (formerly known as MonoSpace) this year. The organizators of the Conference are generously covering the entrance fee, flight and hotel costs so that I can take part in this great event. Besides the talks and discussions, there will be a hackfest with fellow C#/.NET/Mono hackers, where I will work on Banshee and showcase some of the work I did during GSoC.

I’m really looking forward to the event, and want to thank all sponsors of the conference, that make my stay possible, which I couldn’t have afforded all by myself:

Image

The Conference will be kindly hosted at Microsoft New England Research and Development Center (NERD Center), so a special thanks goes out to Microsoft as well!

Image

GSoC final report

Its been great three months, but everything has to come to an end someday. I took the time last week to rebase my patches against latest banshee git master, and submitted all my changes (that were not yet merged like some other patches I submitted during GSoC) to the bugzilla. Thanks to Betrand’s hard work with reviewing them during the hottest weekend this year in central europe, they are (with two exceptions) now fully merged and will be part of the upcoming Banshee 2.5 development release and (if no major issues arise) the next 2.6 stable release.

As a result I just updated the bockbuild tree at github with an up-2-date banshee.py package.

Roundup

I am very satisfied with my work during the period. If accomplished the two major tasks that I laid out in my original proposal: Adapting the bockbuild buildsystem to build banshee and a selected subset of the community extensions (BCE), as well as introducing hardware support on OS X. I am very proud with the hardware support, as this part was a major coding task and involved lot of reading low level documentation, reading C based libraries and OS X kernel framework headers. From a users point of view, it is also a good feature. iTunes, which is the usually the most used player on OS X, just has no support for syncing to Android devices or other mp3 players, locking the user very much to iPhone/iPods. With the now available implementation, users can shift to Banshee  on OS X if they don’t own an iDevice but want a sync capability.

Additionally, lots of bugs that were very obvious and annoying are now gone on OS X, making the overall use far more pleasant than before my GSoC time. I implemented native “File open” dialogs for importing media, which now allows the user to select from external drives, spotlight searches, network shares etc.

Although the GSoC period is over, I will continue to work on the OS X port (and Banshee in general). After the 2.5 feature freeze I will try to work out an annoying gtk-quartz which withholds me from calling banshee “stable” on OS X. It is hard to track down and not related to banshee but to the gtk-quartz implementation, and crashes banshee when doing drag-n-drop.

Thanks to Google for sponsoring the awesome Summer of Code program, and especially thanks to the GNOME foundation for providing a very well-organized mentorship. Also, it’s been great to work with my Mentor and the Banshee community in General, they are all very open minded and friendly people!

Obligatory Appbundle

Since it is the last report in the GSoC row and lots of bugs have been fixed, I rolled a new app-Bundle for downloading. As I am afraid of calling it stable (see above)  and is based on the banshee git master (instead of the 2.4 branch), I am just calling it “gsoc-final-bundle” instead of doing any version numbers or alpha/beta keys. The feature freeze date for 2.5 is next wednesday, and only after then I will provide “OS X 2.5” bundles 🙂

Download Banshee-gsoc-final.dmg here.

UPDATE: Now that 2.5.0 is out, here is an updated appbundle for Download (Lion required!). All my patches made it to 2.5.0, so there are no more external patches applied in this build!

GSoc Report #5 – Bughunting days

I am a little late with my biweekly report, but here it is. Since it’s not too long till the end of the GSoC period and I’ve accomplished all tasks I wanted to do, I focused on bug hunting and polishing the code I’ve written so far.

Volume-WIDGET BUG, GSTREAMER BUG

This is a nasty one and has always bugged me, and I looked into that even before I started the GSoC assignment. When starting an OS X bundle (up to alpha4) you will notice the volume slider is always muted, and stays that way the entire time. Although, you will be able to hear music. Then, when you try to click the volume button, the popup-slider behaves very strangely: It disappears immediately after you release the mouse button, and sometimes won’t even pop up. This “volume button” issue are actually multiple bugs:

  • I found out, banshee uses it’s own custom volume button widget written in C#. I blamed the misbehaving to the custom implementation, and rewrote it to reuse Gtk.VolumeButton provided by Gtk# (which wraps the Gtk+ volume button widget). To my great surprise, using the Gtk.VolumeButton resulted in exactly the same strange behavior when popping up. That was back in the days before I applied for GSoC, and I then wrote a C-based minimal test-case for plain Gtk+ that could reproduce this error using Gtk’s Quartz backend. I reported it to the gnome bugzilla along with the test-case, and sadly it still lurks there unprocessed tagged as unconfirmed. However, I’ve now taken the time to polish and submit the code that replaces banshee’s custom volume widget and throws away lots of code, that is then replaced by only few code since we can reuse Gtk.VolumeButton.
  • The fact that the volume is muted on startup also manifests itself on the linux platform, as I could test with my ubuntu system. However, it’s not that big a deal on Linux since the volume gets set from the GStreamer backend right when starting to playback a track – but not on OS X (thus it remains muted). It took me hours spending in gdb and reading banshee’s C code that handles the GStreamer pipeline construction to find out why that happens. I finally could come up with a small fix that works around that, and also fixes the volume being at level zero on startup on linux (and OS X), which made it already to git master.
  • Since my fix is just a mere workaround, I wanted to really find out what was causing the inconsistent behavior between the Linux and OS X platform. After again spending even more hours in gdb and reading GStreamer docs, I finally could pinpoint it and come up with a cross platform minimal C test-case, to reproduce the issue using GStreamer only. I’ve reported it back and hope it will get fixed soon by the GStreamer guys. One of the biggest problems I had when coming up with the minimal test-case, was that ubuntu’s gcc always failed to link the code, while using the exact command as I did on OS X. After (some more) hours I finally found out ubuntu changed something in gcc that makes it sensitive to the order of the option flags passed to gcc – that’s why I’ve added the compile commands for each platform as a comment in the test-case. Screw you, Ubuntu devs, for not adding a runtime hint when using the wrong order!!

Open media files from finder

I’ve also added support for opening media files directly in Finder. That means, if you install Banshee.app to /Applications, you can simply right click onto any .mp3 file, select “Open with -> Banshee.app”. This works with multiple selected files, too. I’ve opted not to default any file extension to banshee, so installing banshee will not overwrite your associated default media player.

Simplifying the build, include BCE

I’ve also worked to improve bockbuild, so it can be easier used to create application bundles from scratch on a virgin OS X system. I therefore merged the package definition files from banshee-git and banshee into a single package. Whether to build from the stable-2.4 branch or latest git master is now determined by the -r (release) flag upon build. Additionally, I’ve created a separate package banshee-bce, which is responsible for fetching and compiling latest banshee-community-extensions and is build right after banshee. I also fixed a bug that caused the bundle process to fail, because solitary was not yet compiled. Additionally, I modified the bootstrap-bundle script to write the needed environment variables into the MonoDevelop project files. The functions have been there since the early weeks of my GSoC, but until now had to be executed manually.

So, I’ve wrapped up bockbuild that much and added all sorts of auto stuff, that now it should be very easy to compile yourself your own build of banshee:

git clone git@github.com:Dynalon/bockbuild.git
cd bockbuild/profiles/banshee/
./darwin.py -bvdz

Provided you have installed latest XCode along with command line tools and git for OS X (!!!), these three commands are sufficient on a virgin OS X system to fetch and build all sources, and you will end up with a self-sustained Banshee.app residing in the bockbuild/profiles/banshee/bundle.darwin/ folder, including the BCE plugins. Use ./darwin.py  without any arguments to find out what the parameters are for. In the next report, I am going to tell you how you could then use MonoDevelop to start hacking on the banshee source code.

That is pretty much all to report for now. I know, nothing very spectacular added this time, but fixing bugs and lowering the bar for future developers by simplifying build process is important sometimes.

Mountain Lion support

Sadly, my 2008 Macbook white is too old to be officially supported by Mountain Lion, so I can’t test against it. David reported an older version (I think alpha3) to be working on the ML-RC1 out of the box, and in my github repo I reuse the banshee dependency packages from the xamarin repo, so maybe you can just fetch the latest build and run it on ML. Feedback on that would be greatly appreciated from any ML user!

Alpha5 bundle

Here is the obligatory alpha5 bundle, which is the same as alpha4 but includes the above mentioned patches.

GSoC Progress Report #4 – MidTerm passed

This is the 4th post in the series of my biweekly gsoc status reports. Last week was MidTerm deadline, and I am happy to say that I passed my MidTerm evaluation. I am a little ahead of time, actually. I proposed to have a Banshee.app ready with no working Mass Storage yet, but preview USB plug-in detection. The last alpha3 build already had full usb mass storage support working. So I had the time in the last two weeks to polish the hardware support a little.

Sync your music to network shares with Banshee

I’ve modified the OS X specifc hardware detection code a little, so that not only USB devices get recognized, but all kind of mountable volumes that have an .is_audio_player file on them. This allows one to create a fake mass storage device to sync your media to, but it’s actually just a folder on a network share. This can be any kind of network share, like smb or afp mounts, or as I am going to show step-by-step, a remote SSH location mounted by sshfs/MacFusion.

Howto: Syncing to a remote machine over SSH

I want to be able to sync my media collection and selected playlists from Banshee to my linux powered File-/DLNA-/ Server where I store all my music. I’ll only want to carry a subset of tracks on my Macbook, which has only limited disk space. This is how we can enable syncing via SSH (provided you use at least alpha4 build):

  1. Login via ssh to the machine to want to sync to, and create a folder for your Music and put an .is_audio_player into it:
    mkdir ~/SharedMedia/
    mkdir ~/SharedMedia/Music
    mkdir ~/SharedMedia/Playlists
    touch ~/SharedMedia/.is_audio_player
  2. Edit the .is_audio_player file with your favorite editor and have it look like this:
    audio_folders=Music/
    folder_depth=2
    output_formats=audio/ogg,audio/x-ms-wma,audio/mpeg,audio/wav,audio/x-flac
    playlist_path=Playlists/
  3. On your OS X system, install MacFusion (successor of MacFuse)
  4. From the MacFusion tray icon, select “Connect to Server” and enter the ssh:// address of your remote machine. In my case, this is “ssh://timo@orion/home/timo/SharedMedia/”. Replace “timo” with your username and “orion” with your  hostname of your machine. You will need to have setup ssh public key authentication for the connection to succeed!
  5. Banshee will detect the network share as a generic mass storage device. You can now sync your whole media collection or single playlists between the network share and your banshee media database! 🙂

Other improvements in the hardware backend include stability fixes as well as making the “Eject” button working for the external devices.

Native file dialogs

Also new in alpha4 is the support for native file dialogs. Right now, the Gtk file open dialog is just broken on OS X. If you own a system with more than one harddrive (no matter if internal or external through usb/firewire/thunderbolt) the Gtk Filechooser will not display it. Same holds true for any network shares. Only way to access external storage is, if you know that OS X mounts those volumes in your /Volumes path – a fact that is not known to lots of OS X users (and there is no need to, as you got your external Volumes always in your sidebar). Currently only the Import Media->From File/Folder uses the OS X native file open dialog. At other points, its more complicated due to Gtk Widgets being embedded in the chooser. But those dialogs are usually less often used (export playlist dialog, choose cover art dialog).

As usual, with this bi-weekly report I’ve rolled a new alpha bundle which included my latest development progress and all features talked about in this post, as well as all previous posts. Get it here or follow this direct download link to test it yourself!

Source Code

Since the source for the hardware support and the native file choosers will likely change within the GSoC period, I’ve not submitted patches to upstream, yet. However, I’ve setup a mirror on GitHub including latest banshee master branch from gnome, and a branch with my changes (nicely formatted and rebased). A pull request against myself can be used to retrieve a single patch including all my changes for this GSoC assignment. I’ve also updated the banshee-git package in bockbuild to auto-retrieve this patch and build when doing a release build.

GSoc progress report #3

This is my 3rd post in the series of my bi-weekly status reports for my GSoC banshee OS X assignment. This two weeks period was actually quite more fun than the weeks before, as I shifted from doing packaging and bugfixing work (which is sometimes very time consuming and frustrating when dealing autotools and  recompiling packages over and over again to check for regressions) to actual coding work.

Hardware support

Part of my self-set midterm goal is bringing basic support for hardware devices in OSX banshee, in particular to USB mass storage devices. Mass storage devices are very common: From the first generation of mp3 players, the mass storage usb  driver was used to put mp3 files into the players flash memory and it is still widely used today: All recent Android phones support it, as well as low-cost consumer mp3 player sticks and more sophisticated “feature phones” are also often loadable via usb mass storage. That makes having mass storage support in OS X banshee very important.

OS X disk arbitration library

After little research, I found there are several methods to access usb devices on OS X. There is the IOKit framework, that can be used to handle everything usb related, as far as low level device driver programming. Luckily, there is another Framework that is a little higher on the device layer while not being bound too strictly to USB and fits perfectly for our purposes: the DiskArbitration framework. You can use it to hook callbacks whenever a disk device (being a USB/Firewire mountable volume like a usb stick or harddrive, network shares or .dmg images) appears or disappears to the system. So I chose to go for it and started research.

Unfortunately, neither the IOKit nor the DiskArbitration framework are yet bound in MonoMac. That meant I had a number of choices:

  • writing myself a C based glue layer to interface with the frameworks
  • bind the needed function calls myself with DllImport P/Invokes and wrap the datatypes

The first way is usually an easier one from a programmers perspective, as I could do everything in C and just write a very basic public interface that is marshaled by the mono runtime. Future changes in the framework’s public ABI can be spotted very easily, as the C compiler will complain about missing functions or changes datatypes.

However, I chose the second way as usually prefer keeping one language in a project. Banshee uses quite some C gluelayers at the moment, bug there are efforts to remove them and someday have a completely C# based codebase.

Although MonoMac did not bind the IOKit/DiskArbitration framework, there is limited support for the CoreFoundation framework which helped doing a managed-only solution. I did never work on low-level OS X APIs before, neither did I work with MonoMac, so I spent nearly a full-time week digging into the Header files (which turned out to be the best documentation for the API) and finding out about MonoMac, and how I could handle the native CFObject types and marhsal them into C#.

If I had more knowledge about MonoMac and OS X internals, I’d have tried to contribute them to MonoMac by binding the missing frameworks. I am however glad I didn’t chose that in the first place, as it turned out I only needed a handful of funtions wrapped, and especially IOKit is a huge beast with far more complexity needed for my purposes. So right now, there are two small static IOKit and DiskArbitation classes that expose the needed library calls via the public static extern DllImport mechanism.

Hooking into disk arbitration wasn’t the difficult part. Turned out, for device recognition I needed the usb vendorId/productId pairs, and those were not provided by disk arbtitration (as its not bound to the USB bus). It took me days to figure out how to do that, and I had a chance to catch up with my rusty C abilities, as I did the prototype completely in C, and then rebuild it in C#.

Outcome

I managed to get USB device recognition working quite well (as far as I could test). In the latest alpha build (see below), you can plugin usb mass storage devices at will, before or during banshee runs, and we hook into all necessary events (device unmounting, hard usb removal because life is to short to remove usb safely) and banshee will refresh the devices list.

The usb vendor/product ID pairs are exposed, so lots of device abilities are detected automatically. My Samsung Galaxy S (with CM9) is correctly detected as an android device, and I tested a simple USB stick with an .is_audio_player file to pretend it being a MP3 player. There might be glitches with devices having more than one partition on them, I have yet to test that.

Syncing works (again as far as I could test) although I had to apply two non-hardware backend related patches (1,2) to make the process work seamlessly.

As I only have a limited number of devices, I invite everyone to test with your devices, and give me feedback so I can further improve the mass storage support.

Minor improvements

The alpha3 build I put together includes, besides the very large hardware-support patch (that is not yet in upstream as it will likely change in the next weeks), enabled  UPnP/DLNA client support . There was not much to do, just create a bockbuild package dependency and it worked out of the box, same way as it does on Linux.

As the folks from xamarin pointed out to me in IRC, there are known problems with Glib 2.32 on OS X which severely impact performance. The (quite old) gcc Apple ships seems to have problem with gcc interlocked/atomic intrinsic (compare-and-swap and alike). I downgraded to Glib 2.30 by reusing the xamarin package and to my great surprise I could actually feel it. The UI is a little more responsive, but the great change is the playback: While I often had sound stuttering when the system was under load, that is completely gone now. That change is also included in the latest alpha build.

New alpha build release

As I had done with the two progress reports before, I’ve bundled a new Banshee.app (this time alpha3) ready for everyone to download and test. Get it from here and do not forget to read the instructions provided. Feedback is greatly welcome, you could use the banshee mailing list for that.

GSoC progress report #2 – First .app-Bundle available

This is a brief summary of what I did the last two weeks while working on my GSoC assignment. If you just want the latest alpha release in a ready-to-go .app-Bundle, skip to the end of this blog entry 🙂

Community Extensions continued

WebKit

I’ve continued to review some community extensions code and build systems. There is a larger group of extensions (and banshee addins) that rely on Webkit in some way, so this time I investigated whether it’s possible to compile against a recent webkit-gtk release on OS X. David, who is organizing the Mono & GNOME hackfest this year, told me they have Webkit# & Soup# binding improvements on their agenda for the hackfest, and plan to make it work cross platform. So we decided to wait until after the hackfest, and then I get my hands on the extensions relying on Banshee.WebBrowser. I’m very curious of what will come out of the hackfest.

None the less, I took some preparations to have WebKit-Gtk build on OS X. Turned out it’s not that straightforward as expected. I updated the webkit package in bockbuild to latest 1.8.1 release, and added/bumped some more dependencies that it introduces (zlib, libsoup). I encountered a build error in the configure script, complaining about missing XRender functionality – weird, since we don’t use X but Quartz instead. After some searching, I found MacPorts already had a patch, so I added it into the webkit bockbuild package. The configure script went through, but sadly I hit another bug in the WebKit-Gtk buildsystem. I reported it and am still patient to wait if somebody catches up on it until after the hackfest.

ClutterFlow extension

I’ve examined whether or not it is possible to have the clutterflow extension run on OS X. At first I found out, that clutter-sharp is somewhat unmaintained and quite old, the svn server mentioned here was unreachable. I found two github repos with the name clutter-sharp which are quite old and have issues, but thankfully the debian project has a set of patches ready that bring it into a usable state. I’ve applied the debian patches and fixed an issue with missing GNU readlink on OS X, and imported the working/compiling clutter-sharp into a git repo on my github account for future usage. Why future usage? Because after all I found out that the clutter-gtk package never had support for gtk2 with the quartz backend (only X11), and recent clutter-gtk even dropped support for gtk2 and is only compatible with gtk3. Since porting banshee to gtk3 is on the horizon, clutter-sharp/clutterflow  support may be added in the future.

iTunes-like key bindings

After the more or less disappointing results with webkit and clutter, I’ve worked on enabling key bindings in banshee, which were totally broken until now. To achieve that, I’ve switched to the GtkOSXApplication API that gtk-mac-integration provides, which is Cocoa based (instead of carbon). I’ve created a OS X specific accelerator map which overrides the build-in accelerators. I’ve tried mimic iTunes keybindings as close as possible, to make it easy for users migrating from iTunes.

Icon flicker bug

Around the time I started the GSoC project, I merged the xamarin and David’s bockbuild tree together into a single one. Ever since then, there was a very nagging bug with the icons in the sources view, which randomly flickered and disappeared when hovering with the mouse. Someone on the mailing list could reproduce that, so sth. needed to be done about that. As I remember that didn’t happen on previous builds, I searched through what packages got updated in the merge and started to play around by compiling different versions. This is a very time consuming task, as I have to rebuild the full gtk+/gtk-sharp/pango/cairo/gtk-mac-integration stack when changing versions of a single package. After some patient hours I found out that the update to latest cairo introduced that bug, so for today’s alpha build I downgraded to cairo 1.10.2. I will investigate that further, to have it fixed in the upstream versions.

Pango Bug

Thanks to the great work of Kristian Rietveld (and a little work from my side to track it down) , the bug that made us stick with Pango 1.29.5 is now fixed, hence I bumped to the latest Pango release and applied the patch in bockbuild.

Alpha test builds

At the time of my previous progress report, there were some glitches which kept me from releasing an alpha release of a ready-to-roll .app-Bundle. I’ve worked them all out, and actually today I created the second alpha bundle, which can be downloaded from the GNOME GSoC portfolio page or from here. Please make sure to read the instruction on the portfolio page carefully. I think it is already quite usable, but will still crash when doing any drag-n-drop movements. So don’t 🙂

GSoC progress report #1

GSoC coding phase has run for nearly two weeks now and I have quite some things to report on what I was working on during that time.

BCE build system

One core goal of my GSoC assignment is to enable the BCE build system to work an mac. This was actually very easy task to do, as I could just recycle the bootstrap-bundle and profile-configure scripts from banshee, with just some minor modifications. So for now, a ./bootstrap-bundle will prepare the build environment (mainly scan through your setup and set all necessary environment variables, like LD_LIBRARY_PATH and so on), and “./profile-configure darwin” will run the configure script with the suggested enable/disable flags.

BCE compatibility check

After the basic  build system setup was done, I was curious on what modules would compile out of the box – I thought about my previously contributed FolderSync which does not rely on any unmanaged code – and just tried to enable more and more extensions by adding an according “–enable-<extensionname>” to the profile-configure file. For a handful of extensions this worked seamlessly – but for some others I had to learn there were dependencies that had to be build first and thus I created package files suitable for bockbuild.

A very nasty bug in the gnome-doc-utils m4 macros wasted nearly a day of my time – which was mostly due that I am not that familiar with the whole autotools stack. I finally managed to fix it by replacing the m4 macros with the ones shipped with banshee.

OpenVP investigation

The OpenVP extension gave me a very hard time. OpenvP  creates stylish visualisation in banshee on linux, and it’ll be great to have it on OS X. After nearly 2 days of research, I came to the conclusion that its not easily portable, and here is why: The OpenVP extension relies on the nowadays abandoned/unmaintained  Tao.OpenGL stack. I then found that OpenTK offers a compatibility layer to that, so I created a bockbuild package and added OpenTK as a dependency. This allowed to build the OpenVP .dll and enable them in banshee. However, I quickly found that trying to start it would result in EntryPointNotFound exception: The GLWidget that is used by OpenVP tries to call native gdk_x11_drawable_get_xid() which is unavailable – as we use the gtk-quartz backend, not the x11 one. There is no similar function in the gtk-quartz backend, so I was screwed. After a while I found an alternate GLWidget implementation, which is also based on OpenTK and does not reference native code, but leaves that to the OpenTK backend. I could get everything to compile after some fixes and even be able to run, but upon activation banshee crashed completely from within OpenTK. After searching the OpenTK source, I found that the drawable context is setup using System.Windows.Forms constructs – and that didn’t work out on  OS X using gtk-quartz. So after 2 days I decided that OpenVP will not easily be portable, unless there is a more reliable GtkGLWidget that works with quartz. Bummer.

Webkit-based extensions

There are a bunch of extension that require Banshee.WebBrowser which is currently not available on the OS X plattform. I dug into what would be necessary to get Banshee.WebBrowser enabled, which would be very nice because that would allow Amazon’s WebStore to work. Banshee uses at the moment a glue library (libossifer) to embed WebKit within Gtk#. That native glue code links against WebKit directly. I had some failed attemps to get the WebKit source from svn/git (its just huge!),  and the tarball failed to build. I’ll have to investigate this further, especially since there is a GtkWebKit project which could replace libossifer and a banshee branch with some code to replace libossifer with webkit#. I will definitely get my hands on the WebKit-part in the next weeks, but found it too time consuming for the first weeks as I wanted to show some early results 🙂

BCE extensions running right now

After some dependency research, package creation & compilation, I have finally now running and working the following extensions:

  • FolderSync
  • AlarmClock
  • AlbumArtWriter
  • DuplicateSongDetector
  • RadioStationFetcher
  • LiveRadio
  • LastFMFingerprint (required native fftw and libsamplerate packages)
  • StreamRecorder (requires fixed dllmap .config, lame package plus some Makefile fixes)

Discarded extensions

Some extensions just don’t make sense on the OS X plattform, as they interface with software that is usually not present there:

  • Zeitgeist-data-provider
  • Awn integration
  • Telepathy integration
  • Appindicator

I’ve disabled these extension in the profile-configure file so they don’t get build when on OS X.

 The remaining extensions

As with the remaining extension, I do not know yet whether I should port them or there are some problems. I.e., I could get the RandomByLastFM plugin to compile but it throws some exception while running. As mentioned before, all Banshee.WebBrowser dependentand extensions require further investigation. With the clutterflow extension I am not yet sure whether its possible to integrate cutter into gtk-quartz.

Bockbuild changes

Besides some new packages added that were needed by the BCE, I’ve bumped some packages to newer versions, and merged David’s and Xamarin’s branch into my local branch at github. I try to stay aligned with the xamarin branch of bockbuild as close as possible, because most of the gtk-quartz/mono fixes they integrate directly apply to banshee.  However, due to a bug in pango’s CoreText implementation, we are still stuck on an older pango version.

I also rearranged some of the bockbuild util* stuff and added a python script that  allows to write the necessary environment variables directly into a MonoDevelop .csproj file in XML format using the “–csproj-instert=<filename.csproj>” parameter. Check the build howto for more information.

Banshee changes

I’ve also prepared a patch to banshee which switches to the new gtk_mac_* API and drops the old ige_mac_* API . Before I sent this patch upstream, I’ll check whether its possible to completely switch to the new GtkOSXIntegration API, which would use Cocoa instead of Carbon. The patch is included in my bockbuild repo and automatically applied when building.

Build instructions

I’ve created an extensive HOWTO on how to build current banshee 2.4 with the currently running extensions from BCE on the OS X plattform. So if you want to build banshee from source, or get your hands on the code, now is a good time for it 🙂

Unfortunately, there are still some glitches when creating an .app Bundle, so I can’t offer an early alpha .app right now – but stay tuned!