Shotwell 0.7.1 Released

Yorba has released Shotwell 0.7.1, an update to our digital photo organizer.  This release includes:
* Fix for a critical bug that caused Shotwell to crash when deleting the only photo in an event
* F-Spot import now correctly interprets older databases
* Fix for an issue where pressing F11 would not exit full-screen mode
* New Kazakh translation
* Many updated translations including Czech, Galician, Hungarian, Japanese, Italian, Portuguese, and Spanish
* Updated documentation
We highly recommended that all users upgrade.
Yorba would like to thank all of our bug testers and translators for their fabulous work.
You can download a source tarball from the Shotwell home page.
Binaries for Ubuntu Lucid and Maverick are available at Yorba’s Launchpad PPA.

Contributing to Shotwell

Jorge Castro asked for our thoughts on a recent (and highly active) contributor, Bruno Girin.  Bruno provided a mountain-load of energy developing the F-Spot migration code for Shotwell 0.7.  Here’s Jorge’s report as well as Bruno’s story about how he came to work on Shotwell in such an in-depth manner.

We value contributions here at Yorba, and we do our best to evaluate every patch that comes in.  Sometimes the timing might be off — especially if we’re rushing to clean up the final details of a release — but even then we might slip in oh-so-good stuff, such as tag autocompletion that Marcel Stimberg valiantly got in under the wire in time for 0.7.

If there’s something in Shotwell you’d really like to see, if you have an itch to scratch, please consider contributing!  Things you can do to get started (in no particular order):

1. Check out our ticket database for bugs and feature wishes.

2. If you’re not familiar with Vala, acquaint yourself with it — Shotwell is 99.9% Vala.  Fortunately Vala is very similar to Java and C#, so if you’re familiar with either or both, you have a head-start.  Some good Vala resources include its documentation and tutorials, the Valadoc for the various bindings that come with it (here’s the latest Valadoc for Gee, the collection class we use extensively in Shotwell), and my article on The GNOME Journal about why Yorba chose Vala in the first place.

3. Download the source from our Subversion repository: svn co svn://svn.yorba.org/shotwell/trunk

4. Read over Shotwell’s architecture overview and Yorba’s coding guidelines.

Hopefully this gives you a good start on hacking Shotwell.  We look forward to your patch!

Shotwell 0.7 Released!

Yorba has released Shotwell 0.7.0, a major update to our digital photo manager. This release includes a host of new features, such as:
  • Migration support for F-Spot users: Shotwell can import photos directly from your F-Spot library, preserving tags and ratings.
  • Photos can be rated on a 1-5 star scale or marked as rejected. A filter button supports viewing only photos of a specified rating or better.
  • A new Last Import page in the sidebar gives you instant access to your most recently imported photo roll.
  • Sidebar functionality and appearance have been improved with new icons and inline renaming.
  • Numerous bug fixes and translation updates.
We highly recommend that all Shotwell users upgrade.
Yorba would like to thank all of our bug testers and translators, without whom this release would not have been possible.
You can download a source tarball from the Shotwell home page.
Binaries for Ubuntu Lucid and Maverick users will be available on Yorba’s Launchpad PPA within a few days.

Synchronization in Vala

When I first began working with threads in Vala, I was happy to see its lock keyword.  Compare that response to when I wrote my first Java program (wa-aa-ay back in 1996).  I was a bit put off by the synchronized keyword — I still had in me that C-inspired purity that there should be a strict separation between language and library.  I was blind to the idea that critical sections and semaphores should be built into a “serious” language.  I’m sure I muttered something about syntactic sugar and sighed and gave Java threads a try … and loved them.  Critical sections and block-scoped programming really do go hand-in-hand.  It was a joy to know that I could never leave a critical section locked when I exited a function.  That and Java’s intelligent exception handling really sold me on the language.

But when I began coding threads in Vala, I noticed some limitations to the lock keyword.  Firstly (and oddly), the compiler would only allow me to lock member variables of the current object, but not the object itself.  This is perfectly legal in Java:

public void method() {
    synchronized (this) {
        // protected code
    }
}

This is so useful, Java has syntax for locking this throughout an entire method:

public synchronized void method() {
    // protected code
}

So why can’t Vala do something similar?  Why can’t I lock(this) — especially since, if the this variable is a member of another object, that object can lock it!

And I noticed something even odder with lock.  When you synchronize on an object in Java, you’re essentially using an invisible lock() method on the object.  (This is the “intrinsic lock” or “monitor lock” in Java-speak.)  Beneath the covers it’s something like this:

object.lock();
try {
    // protected code
} finally {
    object.unlock();
}

You can see why this will compile in Java but produce its ill-named NullPointerException:

Object object = null;
synchronized (object) {
    // ka-boom
}

However, this code works just fine in Vala:

class Foo {
    Object object = null;
    public void go() {
        lock (object) {
              // smooth sailing
        }
    }
}

What’s the story?  If object is null, how can it be locked?

It turns out that Team Vala have come up with an interesting paradigm for locking variables that (a) works around certain limitations of GObject, and (b) actually cleans up some of my issues with Java-style critical sections.

The key to understanding the lock operator in Vala is to understand that you’re not locking the variable itself.  You’re locking the memory used to store that variable. That’s why Vala can only lock member variables of a class.  The only other storage to lock is the stack, which is rarely (if ever) useful (and probably indicates a design flaw), or global memory, which isn’t such a hot idea either.  (Locking a static member of a class is allowed.)  Jürg discussed this on the Vala mailing list.

Like Java, lock is calling a “magic” reentrant mutex that’s associated with the member variable.  This mutex cannot be reliably passed around with the variable (which would be necessary for code in another class to lock it).  And GObject doesn’t provide a built-in object-wide mutex that Vala can use.  Vala could magically generate one in your own classes, but lock wouldn’t work on any non-Vala generated GObject — including GTK, GLib, and so on.  Hence, this rule is also a nod to the limitations of the libraries Vala is building upon.  To put it another way, lock always works because it can only lock Vala-produced objects.  Ta-da.

And you can lock native types, not just objects.  Locking an int counter is a snap in Vala without resorting to Java’s coarse-grained synchronized(this) or a dummy Object.

Another advantage to Vala’s approach is that it solves one of my gripes of Java synchronization.  Going back to the analogy I mentioned earlier, every Object in Java has an invisible lock() and unlock() method — but those methods are public.  Anybody can lock an object and hold that lock during their six-deep nested loops or blocking calls, even if that lock is relied upon elsewhere in the system (by, say, a thread that very object created and maintains).

Vala doesn’t have this problem.  A member variable is only lockable by methods of its class.  Problem solved.

And go back to the other example, where Java will throw a NullPointerException when synchronizing on a null object.  Because Vala is locking the storage of the reference, and not the reference itself, you can do this reliably and easily:

// atomic singleton creation
lock (object) {
  if (object == null)
    object = new Object();
}
// atomic replacement of multiple fields
lock (object) {
  object = new_object;
  object_modifier = new_object_modifier;
}

You can do the second one in Java, but it’s probably not what you want — most Java programmers will synchronize on this, which may be too coarse.  The only alternative is to generate a dummy Object to lock upon, which is kind of ugly.  Nice and clean in Valaworld.

Shotwell 0.6.1 released

Yorba has released Shotwell 0.6.1, an update to our digital photo
manager.  We would like to thank all of our bug testers and translators for their excellent work.

It is highly recommended that all users upgrade.

Major improvements since 0.5 include:

 * Basic support for RAW images, including import support for all common formats like CR2 and DNG
 * Full support for working with PNG images
 * Users can now zoom into photos
 * A new preferences dialog
 * The ability to open photos in an external editor, such as the GIMP, from within Shotwell
 * Photo tags and titles are imported automatically from XMP and IPTC
metadata
 * A photo trash can
 * Numerous bug fixes and improved language support

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

Binaries for Ubuntu Lucid or Maverick are available at Yorba’s PPA:
https://launchpad.net/~yorba/+archive/ppa

Fillmore and Lombard released

We are pleased to announce the first release of yorba’s multi-media creation tools, Lombard and Fillmore.

Fillmore is an open-source multi-track audio editor for Gnome, based upon GStreamer and written in Vala.  You can record one mono track at a time.  You can create multiple tracks and sequence your audio to create songs, podcasts, stories.  You can export your project to an Ogg-Vorbis file. 

Lombard is an open-source video editor for Gnome, based upon GStreamer and written in Vala.  You can import and arrange your video clips using Lombard.  If you would like to add extra audio tracks for music or voice overs, open up your Lombard project in Fillmore.

We are currently working on version 0.2 of both products and would love to hear what features you would like next.

You can read more about fillmore and lombard here.

JIm Nelson's blog + archives from Yorba Foundation's original blog