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 firstname.lastname@example.org:Dynalon/bockbuild.git
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!
Here is the obligatory alpha5 bundle, which is the same as alpha4 but includes the above mentioned patches.