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.