C++ bindings for monotouch using SWIG

(c) S. Delcroix 2013

I love bindings. I've always loved them. Back in the days, I was binding gtk+ and other gobject libs to C# for fun and f-spot usage. Then I bound some obj-C libs to monotouch for a client and some for pleasure.

But last week I faced something new. I wanted to bind (for monotouch) a C++ iPhone lib for which I only received the binaries and the headers files. The component was too large to even think about doing a manual C glue code. I googled about the possible solutions and the only valuable advice was to use SWIG, without any rationale or tutorial. This is then probably a first. An explanation on why SWIG can help you for this, the problem I ran into and the solutions I found.

Talk Teaser: Image processing with Mono.Simd

The facts:

Processing time using gdk_pixbuf: 431ms
Same method ported to Mono.Simd: 66ms
That means roughly 6.5 times faster !

Some explanations:

• The gdk-pixbuf is an unoptimized standard gdk operation (gtk+ 2.18.1), but I don't think a lot of them are optimized either using mmx or SSEx for this platform (x86-64). Feel free to prove me wrong here.
• Times are averaged.
• Loading and saving times aren't taken into account here, but both are using gdk_pixbuf operations.
• The Mono.Simd method acts on vanilla pixbufs, and results are plain old usable pixbufs, not some kind of memory buffer or whatnot.
  
• The image attached to this post is not the result of the processing.

This is only a teaser for the short talk I'll be giving at FOSDEM on Sunday Feb 7. Be there if you want to learn more, see the code, or question my sanity for doing this in Mono and not directly as a gdk-pixbuf patch.

Mono devroom @ FOSDEM 2010

Mono got a room at FOSDEM2010 in Brussels, so we won't have to do that in the hallway this year !

Want to speak about something fun you did with mono ? Propose a talk. Using mono on your servers saved your company from bankrupt in 200[89] ? Talk about it too. You are a passionate mono hacker and want to spread the word about what we'll got in the upcoming version ? You know the link.

And for everyone else, eager to learn about it, to discuss it, join on Sunday Feb 7. You're all welcome.

Note: be quick, the deadline for the cfp is around Dec 20.

Mono-ifying Gnome3, one dependency at a time

2 quick announcements:

libunique now has a managed binding, Unique#. As the mapping is already feature complete and API stable, the code is tagged 1.0.0. It's simple, it's as easy and obvious to use as the native libunique, it doesn't have funky dependency (except, well, for libunique 1.0.0), it installs itself in the GAC...

The code is hosted on gitorious http://gitorious.org/unique-sharp/unique-sharp and patches are welcome. There's no tarball so far, but if you need one, ask and you might receive.

F-Spot got yet another bugfix release (0.6.1.4) I worked on during the weekend, fixing an X issue on some screens. Unfortunately, the Karmic release of Ubuntu (congrats guys) unleashed a new horde of avid testers, and they were able to find an issue in the --view mode (the same issue, for the same widget, was reported for the facebook exporter too). I'll look at it this weekend, in the meantime the workaround is to run f-spot --view with GDK_NATIVE_WINDOWS=true.

[Update 2009/10/31: bug fixed]

News from the F-Spotters

Some news, in no particular order:

F-Spot 0.6.1.2 was released a couple of minutes ago. It fixes db upgrade for the people who went in holidays in the far future. Now F-Spot can update a db with photos taken (or reported to be) after 2038. It also fixes a crash while running on gtk+ 2.14.

The LiveWebGallery extension is now merged into the main tree, and installable, from the Manage Extension dialog, on any F-spot > 0.6. The extension crashing on gtk+2.14 is part of the past too.

Ruben is MIA. Last time we heard from him, he was "in a park near a pond near a museum".

A new extension, allowing finer control over the BlackAndWhite conversion process is coming soon. It leverages the expensive CPU you paid big bucks for via Mono.Simd. Mandatory screenshot:
That's it for today.

GtkBuilder on IronPython

Someone asked me if I could add the missing parts of GtkBuilder in Gtk#Beans so he could use it with IronPython on mono.

Hey, it looks there's no missing parts ! It all works fine since day one. Here's the the trick:

import clr
clr.AddReference('glib-sharp')
clr.AddReference('gtk-sharp')
clr.AddReference('gtk-sharp-beans')
import Gtk
import GLib
import GtkBeans
import System.IO

def PyBuilderAutoconnect(builder, target):
def _connect(builder, object, signal_name, handler_name, connect_object, flags):
    name = ''.join([frag.title() for frag in signal_name.split('_')])
    event = getattr(object, name)
    event += getattr(target, handler_name)

for object in builder.Objects:
    setattr(target, object.Name, object)
builder.ConnectSignalsFull (_connect)

class Application:
def __init__(self):
    builder = GtkBeans.Builder (System.IO.FileStream ('ui.ui', System.IO.FileMode.Open))
    #use this ctor if you don't like FileStream
    #builder = GtkBeans.Builder ()
    #builder.AddFromFile ('./ui.ui')

    PyBuilderAutoconnect (builder, self)
    self.window1.ShowAll ()

def onbuttonclicked(self, o, args):
    Gtk.Application.Quit()

Gtk.Application.Init ()
app = Application ()
Gtk.Application.Run ()

Now your IronPython skills are ready to rock Gnome3!

Announcing Gio# and Gtk#Beans

For a handful of good reasons (see Mike's mail), gtk-sharp, the gtk bindings for Mono and .NET, lately chose not to follow the hectic 6 months release plan of both gtk and glib teams but leverage on the almost perfect 2.12.x releases we have now (binding gtk 2.12 and glib 2.16) for a few extra months.

F-Spot, that small photo app everyone like, was, in its SVN/git latests versions, using a lot of the new API additions of gtk-sharp. You probably figured that already if you're following its developments.

So I branched out some of the code I needed from Gtk# svn to 2 new standalone projects, Gtk#Beans and Gio#. Both projects aims to fill the gap between the API mapped by Gtk#2.12 and the capabilities provided by gtk 2.14/glib 2.16.

The code is maintained on gitorious http://gitorious.org/gtk-sharp-beans, http://gitorious.org/gio-sharp and is already usable (and used in f-spot). Feel safe to use them as the API introduced over there will be merged with the fewest possible changes to the next Gtk# release.