A couple of weeks ago we had a great day of talks during the first Mono @ FOSDEM Developer Room. What's even more awesome is the fact that Andrius Bentkus took the effort to record all talks. Here they are, together with the slides (the ones I have). Enjoy!

09:15 - 10:00      MonoDevelop
Lluis Sanchez Gual | MP4 | YouTube | Slides

10:00 - 11:00      The Ruby and .NET love child
Ivan Porto Carrero | MP4 | YouTube | Slides

11:00 - 12:00      Mono Edge
Miguel De Icaza | MP4 | YouTube

12:45 - 13:15      The evolution of MonoTorrent
Alan McGovern | MP4 | YouTube | Slides

13:15 - 13:45      Image processing with Mono.Simd
Stéphane Delcroix | MP4 | YouTube

13:45 - 14:15      ParallelFx, bringing Mono applications in the multicore era
Jérémie Laval | MP4 | YouTube | Slides

14:30 - 15:30      Building The Virtual Babel: Mono In Second Life
Jim Purbrick | MP4 | YouTube | Slides

15:30 - 16:00      Moonlight and you
Andreia Gaita | MP4 | YouTube

16:00 - 16:30      OSCTool - learning C# and Mono by doing
Jo Shields | MP4 | YouTube | Slides

16:30 - 16:45      Smuxi - IRC in a modern environment
Mirco Bauer | MP4 | YouTube | Slides

Buy Andrius a drink if you happen to run into him. He deserves it.

Update: All videos are now on YouTube too. The MP4 ones are of much higher quality though.

Last weekend, during the tenth edition of FOSDEM, we had the joy of organizing the first ever Mono developer room. While there had been talks about Mono before (including Miguel's great presentation at FOSDEM 2007), it was still a rather underrepresented topic. For that reason, Stephane and I requested a developer room and gladly we got it.

I was very happy to see the response we got from the call for talks: a very nice selection of talks was submitted. Clearly there was great interest to present at FOSDEM. The big question though was whether we would draw a crowd or if the presenters would have to talk to an empty room.



It turned out that we had nothing to fear: we already had to close the room before 11:00 in the morning to avoid crowding. For the entire rest of the day, we had between 2/3 and full occupancy. Visitors were greeted by a nice selections of talks.



Not only did we have interesting talks, there was a good dialog going on in the room, which I enjoyed even more than the talks. There were some very interesting discussions going on and there was a general feeling of excitment.

Overall (and I think many share this feeling), we can say that the Mono room was a great succes, something we will certainly try to repeat next year. One more reason to attend FOSDEM!



An even nicer set of photos, made by Stephane Delcroix (the ones above are my photos), can be found over here: Picasa. Additionally, the awesome Andrius Bentkus took the effort to record all the talks. These videos should become available soon.

Hope to see you all next year!

Stuff to look forward to at FOSDEM 2010: The GNOME room and for the first time ever: the Mono room. And seeing everybody again, off-course. Can't wait!

I am happy to announce that the schedule for the Mono developer room at FOSDEM 2010 has been finalized. We have a lot of great talks lined up for you to enjoy:

09:00 - 09:15	Opening (Ruben Vermeersch, Stéphane Delcroix)
09:15 - 10:00	MonoDevelop (Lluis Sanchez Gual)
10:00 - 11:00	The Ruby and .NET love child (Ivan Porto Carrero)
11:00 - 12:00	Mono Edge (Miguel de Icaza)
Lunch Break
12:45 - 13:15	The evolution of MonoTorrent (Alan McGovern)
13:15 - 13:45	Image processing with Mono.Simd (Stéphane Delcroix)
13:45 - 14:15	ParallelFx, bringing Mono applications in the multicore era (Jérémie Laval)
Coffee Break
14:30 - 15:30	Building The Virtual Babel: Mono In Second Life (Jim Purbrick)
15:30 - 16:00	Moonlight and you (Andreia Gaita)
16:00 - 16:30	OSCTool - learning C# and Mono by doing (Jo Shields)
16:30 - 16:45	Smuxi - IRC in a modern environment (Mirco Bauer)
16:45 - 17:00	Closing (Ruben Vermeersch, Stéphane Delcroix)

Full abstracts should appear on the FOSDEM site soon. I am very happy with the line-up we managed to come up with, with a lot of good technical talks. Hope to see everybody there, come soon as the capacity of the room is limited!

Are you a developer hacking on or using Mono? Coming to FOSDEM 2010? Be sure to submit your talk for the developer room and do it quickly: the deadline is nearing!

More info.

I am very pleased to announce that in 2010, for the first time ever, we will have a Mono developer room at FOSDEM. This room is organized by Stephane and me, with the kind input of Andreia and many others.

As of now, you can submit your talk proposals! We want to make this a fun room and we want to accomodate all kinds of talks. For that reason, one thing we're experimenting with is having dynamic timeslots. Only want 15 minutes? That's okay! Need an hour? We'll see if we can squeeze it in! The most important factor is that it's interesting and fun.

So send in your proposals, be it large earth-shaking projects, or little hackery experiments that make you giggle with hacker joy, we want to hear it. We have the complete Sunday to schedule. Still have questions? Email me: ruben @ savanne be.

The submission form is here, go fill it in now! (Send in your proposals before December 20)

We hope to see you all in Brussels in 2010!

Together with Mike Gemünde (tigger), I am happy to announce that we are working on adding image support to Taglib#, which is the metadata library used by Banshee and currently only supports audio and video files. So why is this important? Because we will be able to vastly improve the metadata handling inside F-Spot. Furthermore, should Banshee ever decide to add photo support. it'll be ready for them to use.

The aim is to have a usable, complete and solid metadata library. This includes extensive unit testing (to the extreme). If we will handle your files, we want to guarantee that it will be done correctly.

All of this can be found on Gitorious. The code is in the photo-support branch of the mainline repository, master is a copy of the SVN repository for upstream Taglib#. Currently we support JPEG and TIFF, with Exif and XMP (see the wiki for more details). We plan to expand this to every other format out there. More instructions on how to get the code and test it can be found here.

So what's the plan here? First, we will improve the git version as is. When it is ready, we will then start embedding it into the F-Spot tree (while keeping the main repository synced in gitorious), to let it mature. Over time, we'll be working with upstream to have it merged back. I have already talked with Gabriel Burt about this, so this "fork" won't stay around forever.

We are looking for people that want to help us out. By testing it (to make sure we handle your files correctly) and off-course by hacking on it. Much to my surprise, I noticed that writing a metadata library isn't all that hard, so you don't have to be a superhero hacker to be able to do something useful.

Want to help out? Hop onto IRC and join #f-spot (on irc.gnome.org), come and talk to me (rubenv) or Mike (tigger).

Three weeks since the end of GSOC 2009 and I still haven't managed to blog about it. Shame on me! This summer I worked on RAW handling and processing for F-Spot. In the long term, F-Spot should become a capable image processing tool, like e.g. Adobe Lightroom. The purpose of this GSOC was to get a step closer towards that goal.

There are three big issues that need to be solved to get there:

• RAW decoding and loading
• RAW processing
• Repeatable (non-destructive) editing

RAW decoding and loading
RAW files are generally stored in an undocumented, proprietary format, which often varies per camera model. Decoding these files was something F-Spot did not attempt to do yet. During this summer, I refactored the image loading facilities in F-Spot towards a unified loading model, into which I hooked up a new RAW loader, based on LibRaw.

This means that F-Spot can load and display any RAW file supported by dcraw (upon which LibRaw is based). That basically means all RAW files.

RAW processing
A big task in handling RAW files is processing: transforming the raw sensor data into RGB pixels, applying white-balance and gamma corrections, noise reduction etc. All of this needs to happen in a high bitdepth (10, 12 or 14 bit) for optimal quality. I investigated three paths here: reusing the dcraw processing routines, GEGL and hacking it up myself.

Trying to reuse the processing routines from dcraw was a nice way to learn how much of a horror the dcraw code is. Certainly the most bizarre code I've seen to date. Also, these routines were not reusable for e.g. JPEG, which would have meant that we needed to implement things like white balance adjustment twice.

Plan B was to use GEGL, the great image pipeline that will power The GIMP. While promising, it was still way too slow to be usable (minutes of time needed to load one RAW file).

Plan C involved hacking it up myself. This would have meant changing GdkPixbuf to support higher bitdepths and write a ton of very complex computation algorithms.

In the end, I made the wise decision not to try to build a high bitdepth pipeline and focus on the other tasks. For now, I let LibRaw do the initial processing, up to the point where we have an RGB image, which is then handed over to F-Spot for further processing.

Repeatable (non-destructive) editing
The third task was repeatable editing. To go for the Lightroom experience, with all the knobs and wheels to adjust, we needed a repeatable editing framework. Those familiar with F-Spot know that all editing is currently destructive: each operation creates a new JPEG, with the quality loss that goes along with it. I wrote the first version of a non-destructive image processing framework and converted all color operations to it.

It means that we go from:
original --> editA --> editB --> editC

to:
original + adjustment settings --> result

This is a good thing, every arrow means potential quality loss.



So, what's next? Where are we at?
This code is not merged yet, as there are still some things that need to be worked out. Those who want to try it (make backups, your database will be changed!) can find it in the libfspotraw branch on Gitorious. Alert readers will have noticed that we are not there yet, which is true, but given the size of the task, that was to be expected. We are however a lot closer in the right direction. More information and details can be found in my final report email.

In the meantime, I have started hacking on another important issue related to F-Spot. But you will have to wait until I have returned from my trip to Lisbon (leaving tomorrow, coming back Sep 18) for more details.

As Stephane mentioned in his blog, F-Spot 0.6.0 is out.

Some of the highlights of this release (in no particular order):

• This release contains the folder bar, which I previously blogged about.
• This is the first release where we all used Git and it has massively paid off. Contributions are flowing in at a massive rate, from lots of people. See for yourself on Gitorious. Now that the release is out, it's time to go over merge requests. It's hard to keep up with them.
• F-Spot is getting ready for GNOME 3, with the introduction of GIO/GVFS and GtkBuilder. There are still parts of the code using the old stuff, but we're gradually replacing it.
• Bugs fixed! Over 120 bugs have been closed between the previous and the current release. This number does not include duplicates.
• And perhaps the most important: we're retooling things, refactoring and cleaning, which was much needed and will allow us to make it better faster, make it easier to add stuff and simpler to contribute.

With the pace going up and the codebase improving, you can be sure to see great stuff in the future of F-Spot! Oh and if you'd like to help build that future, drop on by on IRC: #f-spot on irc.gnome.org.

Somebody dropped into #f-spot on irc.gnome.org a few days ago and asked:

Fortunately, the answer is yes, F-Spot is very much alive and kicking. It's true, the pace was down for a period of time, mostly due to people getting precious time claimed by other obligations. Things are coming back up to speed lately and that's what this post is all about.

Build problems: resolved
F-Spot was quite hard to build for some time, due to a dependency on gtk-sharp from SVN. On top of that, this led to bugs for some users. Two weeks ago, sde came in and fixed it all.

Building F-Spot should now work on all modern distributions, without the need to install libraries from source. You can get it at git://git.gnome.org/f-spot.

F-Spot and Git: the power of DVCS in action
We've set up an automatically synchronized copy of the F-Spot git repository on gitorious.org. This allows external contributors to branch and publish their work, in such a way that we can track it. This has paid off, as you can see over here: http://gitorious.org/f-spot/. There's a buzz of activity with lots of cool branches being worked on. We love git, many thanks to the guys that made it happen, it's making our work so much nicer!

What's cooking
Here's a short rundown of what people are working on (remember, this is all very experimental and beta, no promises on it ever getting released):

• Mike Gemünde (tigger) is currently cleaning and refactoring quite a lot of IconView code. This will get our codebase into a much leaner shape, which will make future modifications much easier. He is also working on adding geotagging.
  
  
  
  Setting geodata (click for larger version)
• Paul Wellner Bou (piz) is working on a lot of stuff, including a nice extension that allows you to compare different image versions.
  
  
  
  Compare versions
• Lorenzo Milesi (maxxer) is taking care of bugzilla. Incidentaly, he also blogged about all this stuff. This is not coordinated, but it does nicely confirm the extra buzz I was talking about.
• Wojciech Dzierzanowski is working hard on Tabblo exporting to make it rock hard.
• And as for myself: I've been prototyping some stuff related to progressive image loading and preloading. I'm also looking into RAW processing for my GSoC. All of this is going at a rather slow pace as I'm in the final stages of writing my masters thesis.

Many hands make light work
It's true, F-Spot is far from perfect and we're all too aware of that. Also, there's so many cool features that we want in there, but haven't found time to build it yet. But we all want to build the nicest photo app there is.



And you can help with that! If you know how to program, join us on IRC and feel free to poke me. Many hands make light work and currently most of our hands are already overoccupied. We have plenty of feature requests already, so unless you want to program them yourselves, you'll probably just have to wait for it.

UPDATE: Due to me incorrectly parsing gitorious.org, I wrongly quoted Lorenzo as doing the Tabblo work. While he is helping to get it merged, it is Wojciech who deserves all the credit for the development, sorry for that!

While figuring out why Tomboy takes quite a lot of time to start (BGO #567989, hint: it's not the lack of SQLite), I was reminded of Lord Kelvins old saying: "To measure is to know".

Thinking how to quantify this, it occured to me that the GNOME community has the perfect tool for figuring out slowness: Federicos awesome timeline tool. All I had to do is figure out how to use this with Mono, which is very easy, as you will see below.

Federico uses a nice trick using syscalls, which are logged using strace. Fortunately, this is very easy to reproduce with C#.

1. First we need to generate them, add something like this to your program:
   
public class TraceLogger {
    public static void trace (string group, string format, params object[] args)
    {
        string message = String.Format (format, args);
        string str = String.Format ("MARK: {0}: {1}", group, message);
        Mono.Unix.Native.Syscall.access(str, Mono.Unix.Native.AccessModes.F_OK);
    }
}

2. Liberally sprinkle tracing statements in your code, like this: TraceLogger.trace("Main", "Starting main loop");
3. Modify your startup script so that the line containing "exec mono ..." now reads "exec strace -ttt -f -o /tmp/timeline.strace mono ....".
4. Use Federicos script to plot it: python plot-timeline.py -o graph.png /tmp/timeline.strace.

That's all there is to it. The attentive reader will notice that I used the tracing format a bit differently, rather than printing the program name, I use a group parameter. This makes the graph easier to interpret: if you add too many tracing statements, it might be hard to see where the big gaps are. Hijacking the color coding avoids this interpretation difficulty.

Now hurry up and make your Mono apps even faster!