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!