F-Spot war ein Aushängeschild der Mono-Entwickler für den Linux-Desktop. Doch schon bei einem der wichtigsten Features von Mono, der Plattformunabhängigkeit, konnte F-Spot nie wirklich auf Erfolge verweisen. Unter Windows lief die Bildbearbeitung nicht zufriedenstellend, und das Projekt scheint gescheitert. Im Interview mit Linux-Magazin-Autor Tim Schürmann erklärt Timothy Howard die Probleme und gibt Tipps fürs plattformunabhängige Programmieren mit Mono.

Linux-Magazin: What and where are the biggest problems or obstacles? What is more difficult: To port the GUI or the unmanaged code?

Howard: The biggest obstacles as I recall them fell into one of three categories: unmanaged code, managed but platform specific code and issues revolving around GtkBuilder or more generically GUI code. At the time I was doing most of the work (almost a year ago) there were a number of issues with GtkBuilder processing a Glade XML layout file that would cause crashes in F-Spot immediately at launch. I started manually building the XML layout file with just the most basic elements until I could get something that worked. The problem seemed to be centered around the signal handlers. If I left those out it would build the GUI fine. I then had to programmatically setup the signal handlers during object construction. It wasn’t ideal but it wasn’t long term either.

“Mono und Gtk# sind nicht gut in Gnome integriert”

Another problem facing someone more generically, I think, with tasks like this and others in the open source community is a matter of best practices. Since Mono and Gtk# seem to be less embraced by GNOME than other languages/frameworks/runtimes, etc. there is a lack of information as it relates to things like, “you should use this, but not this”. For me that was definitely the case when I encountered problems with GtkBuilder. There were voices saying abandon it altogether and yet it seemed to be an established part of the current Gtk/Gtk# build process. Certainly it was through F-Spot and was definitely not something I was willing to tackle in the process of a “simple” port.

There were several issues with older code in F-Spot that is managed but is not written in a platform agnostic manner. Particularly as it starts to relate to things like disk access and paths. Again, it was quite old code and never intended to be cross-platform at that.

The problem with unmanaged code is straight forward so I feel no need to expound.

Linux-Magazin: Which parts of F-Spot are reusable and which can’t be ported? Is it possible to port the whole F-Spot code?

Howard: In general I would say it’s all portable with minor changes and the exclusion of the unmanaged parts. The unmanaged parts are portable too (as are all things really) but require more work.

Linux-Magazin: And what was easy to port? Where and in which cases did/does Mono help you?

“Alles, was auf den Base Libraries basiert ist einfach zu portieren”

Howard: Mono doesn’t directly help you with a port in anyway and since it’s already an application running on Mono there are no applications that I’m aware of that do any sort of platform analysis. If you had a .NET application and wanted to check compatibility with Mono then you could use MoMa (Mono Migration Analyzer). As to what was easy to port the answer is basically everything that relied on the BCL (Base Class Libraries) and managed code that didn’t access the disk in a platform specific way.

Linux-Magazin: What were your (first) steps? How did you proceed? What is your “porting strategy”?

Howard: My first steps, as this was my first attempt at such a thing was to get a basic shell of F-Spot working. I figured if I could get the main window building and launching then I would at least have a base to work from. So that’s where I started. I also started with a bare project and added to it rather than trying to start with the entire codebase and making it work. I found it rather easy, once I figured out the GtkBuilder issue, to get F-Spot starting, reading the sqlite database and displaying photos.

Linux-Magazin: What advice would you give a programmer who wants to write portable programs using Mono? What should he take care of?

“Mein Tipp: Schaut euch erfolgreiche Portierungen wie Monodevelop oder Banshee an!”

Howard: I think the best advice would probably be to just look to the really successful cross-platform applications that exist today. Starting an application today, using Mono and staying cross-platform is a trivial task compared to just a few years ago. However, on its own it’s still something that requires effort but at least there are significant examples like MonoDevelop and Banshee.

Linux-Magazin: What are your experiences with Gtk# and GTK in windows? Are they stable? Would you say, that they are stable and reliable enough to build productive programs with it?

Howard: Other than my port attempt and some rather trivial other things I do not have a lot of experiences with Gtk# and Gtk on Windows. However, it’s easy to reference MonoDevelop and say it’s absolutely stable and possible to build productive programs with. GIMP would be a validation of GTK on Windows. Perhaps the biggest problem is that they lag behind somewhat and/or rely on unofficial builds.