Chipmunk bindings for MonoTouch

(c) S. Delcroix 2013

I'm quite pleased to announce the availability of Chipmunk bindings for monotouch. I started that last year, and bound just enough of it to get a sample working, added some constraints lately in order to place labels, and completed it since for the beauty of the task. The image next to this is a screenshot from a system using a motor, a gear joint, pivot joints and some more.

At this point in time, the ~2000 lines of manually crafted lines of code can be found in this pull request, but you probably won't have to wait long before it's merged in the monotouch-bindings repository.

Our business app doesn't need your game development skills (using damped springs to place labels on a map)

The problem

Positioning labels on a map, a chart, a plan is a problem every UI developer face at one time or another if he has the chance to work on rich business app. This problem is NP-Hard for non-trivial cases. I faced that issue twice. First while building a silverlight charting library, and then very recently for positioning labels around a pin on a plan. This post isn't about how we solved those two cases. For the charting problem, we went for an algorithmic solution which was working but not optimal. For the second, I don't know how they solved it as I didn't took the job.

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.

DeepzoomIt: a simpleminded DeepZoom composer

Now that Moonlight supports DeepZoom for more than a year, it's about time to fill the blanks and allow one to create deepzoom images, even on linux.

DeepzoomIt does just that.

At least for the simple cases, i.e. no collection support and no selective resolution. But it generate files just right, as shown below (might not work on some planets) .

DeepzoomIt uses gdk_pixbuf for image cropping, scaling, composing. And it shouldn't be sensible to the inability of gdk_pixbuf to scale images bigger than 65536px.

The code is available on gitorious, use it if you like it: http://gitorious.org/deepzoomit.

[3159x2591 sized to viewport via DeepZoom. (shift-)Click to (un-)zoom. Drag to Pan]

[Update 2010.01.11: replaced the pure xaml viewer by a managed one. Pan+Zoom works.]

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.

Unleash your (F-Spot) toolbox

Rumor has it that, during latest UDS, Ubuntu planned to drop Gimp from the default distro and the LiveCD. I won't comment this decision as 1) I have no clue if that's a rumor or more, 2) it was already commented too much, 3) I'm not a whiner, 4) there's a rationale behind that decision and I think I understand it, 5) the full Gimp is only one apt-get away.

But some were concerned about the lack of basic image editing. Enters F-Spot, the loved Photo Manager and his little brother, the --view mode. The --view mode is a standalone application, which, on top of F-spot loaders and widgets, provide a simple (ala eog) image viewer, which only view the images, and let you browse the metadata. This is it. Or was it 1h30 ago. With very few code, I plugged the main F-Spot editors inside the single view mode. And that worked quite well !

Of course, F-Spot editors are nowhere close to Gimp's, and don't even aim too. But they cover 90% of your daily usage and are (probably) simpler to use than Gimp. And even more, you can write (read contribute) some additional ones in very few lines of code. e.g. the BlackAndWhite extension is 120 lines long with the UI, despite behing optimized to run on Simd !



Expect this to be available soon on git, and a bit later in a release !

Multiple branches and translations

Fellow Package Maintainers,

How are you dealing with this ?

I guess f-spot is not the only project maintaining multiple parallel branches, a STABLE one, from which the releases and bugfix releases are created, and a master, open for business, new stuffs, and experimentations.

When we need to correct something on the STABLE branch, we push a new commit over there, then merge the STABLE back to master so it gets the same fixes. That works fine.

But it gets harder with translation commits. Most of the (awesome) translators (well, all except of one) translates the master and commits right there. Then, when it's time to release, I either ignore those translations (and that's seriously annoying for translators who pushed soem work in the .po), or I blindly backport (cherry-pick) the translations back to the STABLE branch and hope that no strings was removed in master's code. Then I merge the STABLE back to master. Both solutions are seriously suboptimal. Really.

I know how this problem is "solved" in most of the GNOME projects by putting deadlines and code freezes, and string freezes, but I guess we're not the only project around with this kind of issue.

The ideal workflow would be to have the translators (hey guys) aware of the STABLE branch, make them translate that branch, have them merge it back to master, and then, optionally, translate the missing/changed strings and commit that to master. I said ideal, cause I'm NOT gonna ask any translator to understand and follow this, be able to maually merge if something goes wrong, etc...

Translators (did I say thanks for your job lately) are already doing an ant job, most of them with no tools but a text editor, and we can't really add any pain to the process.

So, what are you doing in that case. How could we improve the process ?

Comments are open.