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.

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]

Every now and then, it's time to...

Regenerate a new keypair

The old keypair served me well during those past 8 years, but I managed to screw it up in the process of upgrading to opensuse 11.2 rc1. Here's the new public part:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.12 (GNU/Linux)

mQENBErpajsBCADVpFuXevFtqwT44k5b3fAzWLlLKm0JkawrtFir/lpkZp4SMFrn
ZiQ+4I5OOcptmpQfZ6oLqE1P2pGUsl9H0V9CxI9NOK+z2dQBh36ccPPLXhjtG/wO
rIymJJ0UBVRjGUL+1IhGXI3u/BVY1yzEahCUd2gf3BpJkE8COvB6ewL2KPvCfery
vx5Ot0xAqfKVCAtJ8DEVeeVW+//s++DzdiTMqbRzMApM44rT/nd3ebhx/lEb8Opo
143JZKqyrlJ18f0B6CwVjufvnwqb5fvAA9TWRZ3qfbSvRQcRvhaSnAjR1WiDdmhO
FdJJwFLDfcx9vz8snCoB5aqjLXq+AncuhnTtABEBAAG0KVN0ZXBoYW5lIERlbGNy
b2l4IDxzdGVwaGFuZUBkZWxjcm9peC5vcmc+iQE2BBMBAgAgBQJK6Wo7AhsDBgsJ
CAcDAgQVAggDBBYCAwECHgECF4AACgkQYrBLwhj7hs4PGQgAzX4/Xpbz/g5LP6LU
huNi3mabC/SUfQ/jHfO+0pHpF2jTxaUF+eCdEC86FOZubtTHtvSN9tFBWgazvDaW
HvFBQgKBfjaWUHOXXeMkPsWhOkXIqaEE2kYHuqLrijDNgtTq/So1PcPIpAJsY1rr
No++7xKvC9/usEDlnrcz8D7jyyZN/6FGFMZ2YlxCq2qV7+6yJUK4XpLdrLIYChGW
IlLHL4jrHHwnEDtSg7aTMGK+gy4U2ha/rzcEtOS5ec1Tx3MrkWc2Z3BGHZDDTtJd
xeE85GsxsYWNWgt1XzwuHrvK7yPq3Udvgthqpi//VqXfA5S98edJQNc8BXIBYZ7S
90FB4rkBDQRK6Wo7AQgAr5exsNtPs3EW901frwoVFlZLSwWYJDESUJLK7CLS+B+I
fIwPWTP/v+VkaJqJNdjZkXx9d78XFjG0nb/o4xo2m7moCr/+7HnkE/7CdXmepzgU
oZ9EK1PWyPARYVD6JWAG0NQ/SzcEKqJyo+SCfNgVEdq/ls28zXVM0dzBRjOV5sQg
+fksv91d3cPo3+RKpdHfxAUTaW11nsgXiWofx6wbKvKQl2DSjB+8I+YnfAUaRtJq
2BfYHAl8eXvdMhnwkFNIpMQQ8T5phEHJEcp2k6D03HBIwWEkcIG6OLu3g2XGgC8p
z7o8ktRhUre6dEFDCaX2gYMDKviPikqOOlGvNKRgcQARAQABiQEfBBgBAgAJBQJK
6Wo7AhsMAAoJEGKwS8IY+4bOE7cH+wcnAxDYsnnT8NakDqflpzFgtD2r1SLE1J1s
aKk0XXtSSQWQSpxC7YEm9W37SyCBoajPoganWq8FT28VrRV2OqTi88QFOezvgZIW
VoRJHlrtXj3qvdSkF7zImOzCJpN3bKsp+SSO7Kp9KJ3ypGk7ozkgzArB45C6Ydnx
lxcKuoGpb/lr89c/COq4vsaRw4DaXwYbruFITNvRQyq9rZnnYzLnVvZMvmFWU9JI
NCGa5zJbXeNxBUNYpGA3GjaS5ACeVKyHVIJCG4rlxVW/w4AcrHVv+GqIXcuQWuKN
Io2gaZLUPV38CoeKCWWedvTFtYTqHOcHW9iGofr2kEKbz6kXCQA=
=QzP8
-----END PGP PUBLIC KEY BLOCK-----

Fixes by pack of 12

Important things first, just know that Ruben is no longer AWOL. He's even back to hacking mode, and working, together with Tigger, at adding image metadata support for images to taglib-sharp.

Now to the futile, I just released F-Spot 0.6.1.3 a few minutes ago. The main purpose of it was to fix the slideshow mode on gtk+ 2.18 (which we did) and as I was at releasing, I applied some pending patches from bugzilla, wrote some myself, and backported translations from master.

The change in the importing code is worth noticing. It no longer imports the files first to memory before writing them to disk. It's quite helpful now that most cameras can create video files bigger enough to fill your machine memory in less than a few minutes (at high bitrate, on HD resolution). It's only available if you have libgphoto2 >= 2.4 and doesn't work with the directory driver (used for memory cards e.g.). Marcus is working on a fix in gphoto2, so stay tuned.

If you ask about the screensaver, it still doesn't work with gtk+ 2.18 but works fine with gtk+ master, and will still work just fine with gtk+ 2.18.1 when it goes out.

That's it. Download it, build it, package it, enjoy it!

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!

Awesometastic

I woke up this morning with an awesometastic merge request from Anton Keks. During the night (or was it already started weeks ago ?) he wrote a LiveWebGallery extension for F-Spot. It means that you can, using a web browser, see the whole (or only parts of) photo collection of someone else in your local network.



The HTML/js UI is pretty slick even !

The code is not merged yet, but I packaged the extension and it's now installable from within F-Spot (> 0.6.0.0) from the "Extension Manager" dialog.

More details can be found on Anton's blog.

[Update 2009/09/15. The code is now merged]

It's gonna be legendary

wait for it... F-Spot 0.6.1.0 is out!

This one is coming quite soon after 0.6, and contains only fixes, cleanups and translation updates.

It aims to be a packager friendly release, as it drops some bundled code, some dependencies, a few megs of code, and more than a megabyte of installed size !

So, if you were using or packaging 0.6.0.0, jump in now, enjoy the .1.

[Update: I pushed 0.6.1.1 to avoid a reported build issue]

Pit Stop

On our way to F-Spot 1.0, we slowed our well oiled machine to change the tires, fill the tank and do a complete check against the various regressions we might have added while packing tons of new features and changes since the 0.5.x releases.

The truck is now ok and ready to ride to the next milestone. Check 0.6.0 in order to make your own opinion.

Neither this short post nor the NEWS file reflects the really hard work pushed by our contributors, translators and designers, but rescanning the git log this evening reminded me how hard we all worked for this. Thanks guys.

Get it here.

Report on F-Spot loading times

before: (on 0.5.0.3, averaged loading times on the first 10 items of my collection)
Loading image took 1.292241s

after: (current master, averaged on the same 10 items)
Loading image took 0.518812s



[UPDATE] Yes, that's on a dual core machine (Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz).

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.

Renewed f-spot artwork

Thanks again jimmac.

Wire it at the processor level

[Update Mar 17. Fixed the cp/paste issues in code snippets]

«Wire it at the processor level» said my wife when I asked her how she'd compute indices of Morton's Layout.

A morton layout is a way of arranging tiles that grew up in a fractal way. It's pretty neat, doesn't waste too much space, and he's extensively used by DeepZoom/SeaDragon/MultiScaleImage in Silverlight.

It looks like this:

0 1 4 5 16 17
2 3 6 7 18 ..
8 9 12 13
10 11 14 15


One way to compute the position (x, y) of each tile is to take the even/odd bits of the number and remove the white spaces. e.g., 14 is 1110 so x will be 10 and y 11. Got it ?

First approach:
my first implementation was looking for the x, y values in 2 tables of 256 items. Easy and Fast. But sites like Memorabilia uses way more than 256 images. That's the point of using DeepZoom technology, displaying tons of stuff and zoom on the interesting parts.

Looping:
My second attempt was using a loop, some masks and shifts. Not as nice as it could.



void
morton (int n, int *x, int *y){
*x = *y = 0;
int i;
for (i=0; i <>> (2*i) & 0x00000001) <<>> (2*i + 1) & 0x00000001) <<>


One Step, No Loop:

And here's my current implementation, could you find a better way ? (yes, I know, I could save 4 masking operations):



void
morton (int n, int *x, int *y) {
n = (n & 0x99999999) + ((n & 0x22222222) <<>> 1);
n = (n & 0xc3c3c3c3) + ((n & 0x0c0c0c0c) <<>> 2);
n = (n & 0xf00ff00f) + ((n & 0x00f000f0) <<>> 4);
n = (n & 0xff0000ff) + ((n & 0x0000ff00) <<>> 8);
*x = n & 0x0000ffff;
*y = n >> 16;
}



That was a fun evening. And thanks to my wife for challenging me to do this as close to the wire as possible .

A gift to the competition

For once, I didn't spend my weekends hacking time on patches for F-Spot. Instead, in my journey addressing an old and vocal request, I ended up writing xcf files support for eog, gthumb, gqview, F-Spot obviously and maybe some more.

The code for this is a GdkPixbuf loader, based on this specification (moved there since) and some xcf hexdumps, meaning it's suitable to be released under the LGPL for gdk-pixbuf inclusion. (Googling around, I found some mail archives stating that the GPL(The Gimp)/LGPL (gdk-pixbuf) issue was preventing the inclusion of a loader based on The Gimp's code in gdk).

Features:

• read xcf files up to v002,
• compressed and rle-encoded,
• grayscale and rgb color modes,
  
• supports all kinds of layer blending,
• supports layer masks
  

TODO:

• .xcf.gz and .xcf.bz2 support (for jimmac),
• indexed mode

Clone this piece of awesomeness from git://gitorious.org/xcf-pixbuf-loader/mainline.git and report bugs by e-mail. Build it, copy the .so next to the others loaders on your system and run gdk-pixbuf-query-loaders[-64].

(Get the sample file I used for those screenshots from there)

ChangeLog entry

2009-03-09 Stephane Delcroix <stephane@delcroix.org>

* Initial revision