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!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s