Monthly Archives: March 2012

Announcements, Shotwell

Shotwell 0.12.1 Released!

Leave a comment

Good evening,

Yorba has just released Shotwell 0.12.1, a bug-fix release of our popular GNOME-based photo manager. This version fixes a critical issue in which the absence of a certain .ui file would cause the application to fail to launch in direct-edit mode.  We advise that all users upgrade as soon as possible.

Download a source tarball from the Shotwell home page at:
http://www.yorba.org/shotwell/

Or grab a binary for Ubuntu Oneiric at Yorba’s Launchpad PPA:
https://launchpad.net/~yorba/+archive/ppa

For Ubuntu Precise users, this version should soon be made available automatically as part of the daily update process.

Apologies to those who encountered the missing .ui issue, and thank you for your continued interest in Shotwell!

Cheers,
-c

Announcements, Shotwell

Shotwell 0.12.0 Released!

14 Comments

Good evening, one and all,

It’s my pleasure to announce the release of Shotwell 0.12.0. This version represents several person months of hard work, saw us add our one-hundred-thousandth line of code, involved a quest that took our merry little band of adventurers half way around the world, three new brave warriors joining our party, and the slaying of many, many monsters.  It’s now more stable than ever before, has a neat new straightening tool, and, thanks to the watchful eyes, thorough bug reports and helpful suggestions of you, our userbase, it’s pure awesome (I admit there may be some bias on my part, but still…).

We’re proud of it, and on behalf of the team here, I sincerely hope you enjoy using it.

Cheers,
-c

Download a source tarball from the Shotwell home page at:
http://www.yorba.org/shotwell/

Or grab a binary for Ubuntu Oneiric at Yorba’s Launchpad PPA:
https://launchpad.net/~yorba/+archive/ppa

Ubuntu Precise will ship with Shotwell 0.12.x pre-installed by default, so Precise users will be upgraded to Shotwell 0.12.0 automatically as part of their regular software update cycle.

Hacking

Avoiding the association by hash map anti-pattern with GObject

Leave a comment

There’s a common anti-pattern in software design that I call “association by hash map.” Rather than explain this in words, let me illustrate it in Vala:

HashMap<MyClass, string> name_map = 
    new HashMap<MyClass, string>();

name_map.set(an_object, "Foo");
name_map.set(another_object, "Bar");

stdout.printf("an_object's name is %sn", 
    name_map.get(an_object));

“But wait,” you’re saying, “Couldn’t we just add a name field to MyClass and remove the hash map?”

YES! That is exactly what you should do — if you can.

But what if you can’t?  Adding a field isn’t always an option.  Perhaps MyClass is someone else’s API.  Or even if it’s contained entirely in your code, the name field might only make sense for a single use-case.  No reason to add an extra field to your class if it doesn’t truly belong there.

So what to do? Is there a better way? If your class is based on GObject, you’re in luck.

During a recent code review, Jim pointed out to me that GObject has methods for attaching arbitrary named data to an object.  In our example, we can use the simplest of these methods, gobject_set_data() and gobject_get_data() which use simple key/value pairs.

const string NAME_PROP = "name";

an_object.set_data(NAME_PROP, "Foo");
another_object.set_data(NAME_PROP, "Bar");

stdout.printf("an_object's name is %sn", 
    an_object.get_data(NAME_PROP));

Isn’t that better?  No more extraneous hash maps, all the data is stored right in the object itself where it belongs.  And you didn’t even have to modify the class!

In closing, if you’ve dealt with the association by hash map pattern before you now know a way to avoid it with GObject.  And if you haven’t, I envy you.

Hacking, Shotwell

The 100,000 line question

2 Comments

Clinton Rogers (Yorba developer and all-pro Telestrations master) pointed out something interesting yesterday.  Ohloh now lists Shotwell as having achieved an odd milestone just ten days shy of its third birthday: Shotwell has reached 100,000 lines of code.  That number represents the work of 51 code contributors and 89 translators.  (It also represents blanks and comments — 100,000 lines of pure code is a ways off.)

It’s an odd milestone because there’s a rosy tradition in computer programming of honoring tight code and efficient algorithms.  The code placed on pedestals are not thousands of lines long, they’re short and sweet, like a witty joke or a clever haiku.  Duff’s Device is my favorite example; you probably have your own.  (Tom Duff’s history of his Device is a great short read and offers a basketful of concise observations on code optimization.)

Which is why reaching the 100,000 mark makes me simultaneously proud and a little uncomfortable.  Shotwell has grown quite a bit in three years — but is it really doing the work of 100,000 lines of code?  Ur-spreadsheet VisiCalc was also 100,000 lines of code, pretty lean compared to the Macbeth that knocked it off its throne, Lotus 1-2-3 (clocking in at 400,000 lines).  Compare that to the original Colossal Cave game, which was (gulp) 700 lines of FORTRAN and 700 lines of data.  It later grew to a whopping 4,800 lines of code and data that ran entirely in memory.  100,000 lines of code feels downright luxurious, even bourgeois, in comparison.

(I’m not claiming Shotwell should be placed alongside these landmarks.  It’s just interesting to consider what 100,000 lines of code represents.  I’m also aware that there’s a number of people who think line count is a misleading, or even useless, metric.  I do think lines of code provides some scale of complexity and size.  I’ve never seen a program grow in size and get simpler.)

There’s probably no reason to duck my head in shame.  Sure, there’s plenty of features we want to add and bugs we want to squash, but those 100,000 lines of code we have today are pulling a lot of collective weight.  They include the basic organizer, a nondestructive photo editor, a standalone image viewer (which also includes an editor), hierarchical tagging, stored searches, ten plug-ins, and plenty more.  Could we scrape away 1,000 lines of code and still have the same functionality?  Almost certainly.  10,000?  I can think of a few places where fat could be trimmed, but I don’t think it’s excessive.

Note that Ohloh is counting lines of Vala code, not the C generated by valac.  Although valac does not exactly produce sparse output, it’s worth mentioning that sloccount reports over 720,000 lines of C code generated by Vala.  If Vala is producing on average six times more C code than a competent human programmer (and I’m not asserting it does), that’s 120,000 extra lines.  Reducing that by the magic factor of six means Vala saved us from writing 20,000 lines of C code, a victory worth popping open a can of beer and celebrating over.