Category Archives: Shotwell

Shotwell 0.14.1 is Here!

We are pleased to announce the release of Shotwell 0.14.1, the first maintenance release in the Shotwell 0.14 family. Shotwell 0.14.1 is a significant update to Shotwell 0.14, boasting the following features:

  • Fixes a critical issue where Shotwell could close unexpectedly when working with RAW photos in direct-edit mode
  • The Facebook Connector now recovers smoothly from type 7 errors
  • EXIF-oriented photos uploaded to Facebook now appear in their correct orientation, even when the strip metadata option is turned on in the Facebook Connector
  • Fixes an issue where incorrect view filter settings were applied on tag and event pages
  • The Camera Developer is now disabled for RAW images that lack a suitable paired or embedded JPEG
  • Updated translations for many languages, including an updated Catalan translation that corrects a problem where incorrect event dates could be displayed
  • Assorted smaller bug fixes

The Shotwell 0.14.1 tarball is available for download immediately. Ubuntu users can also find pre-packaged binaries for Ubuntu Precise (12.04) and Ubuntu Quantal (12.10) on the Yorba PPA. Shotwell 0.14.x will ship as the default photo manager in the upcoming Ubuntu Raring (13.04) release. Raring users will receive Shotwell 0.14.1 as part of their normal software update process.

Shotwell 0.14 released

The Shotwell programmers, with plenty elation,
Present to you all our fourteenth iteration.

Among the tasks on which we’ve made movement,
Here are some highlighted bits of improvement:

If you shoot in raw, you’ll like it much better now –
It’s smarter at keeping paired images together now.

If something should happen and importing fails,
we’ve better reporting and can save the details.

For Facebook, the app has been Graph API‘d,
And now lists your image folders on the left side.

The slideshow’s enhanced with several new types
Of circular, checkboardular, nifty new wipes.

Along with all this come many bugs fixed,
UI nits squashed and glitches – now nixed.

It’s the very best Shotwell there ever has been –
Go on, download it, give it a spin!

Update for Precise users:
Ubuntu Precise users take heed
of a warning of significant importance indeed.

The Yorba PPA requests for software
that your apt-get may not yet be aware.

Add the GStreamer PPA to your repositories
and refresh the list of your package inventories.

Now Shotwell 0.14 is ready to be had!
Though one may wish to install gstreamer plugins “ugly” and “bad.”

The Garden of the Forking Paths

A thought experiment:

A software developer decides to write an open-source GNOME desktop application that interacts with any number of Internet services, such as Facebook, Gmail, Flickr, and so forth.  It’s not specific to any one service, however.  The app should take advantage of all the available desktop technologies, not only to leverage all that hard work, but also to be a good desktop citizen.

The first thing the application does is log in to an Internet service.  What should this developer do?

(a) Handroll the authentication code.  Most Internet services use a token-exchange system, but each service is different, so the developer will need to write custom code for all of them.  The user will want the application to save the password for next time, so better look into keyring solutions.  And there’s always the problem of where and how to store long-term tokens, since every service has its own Terms of Agreement.  And don’t forget to request Application Keys — each service has its own.  Some services have different entry points for their various “faces” (i.e. Yahoo! and Flickr) while some have a federated login system (i.e. Google).

Halfway through the process the developer thinks, “Why am I reinventing this wheel?  A lot of applications could use this code.”

Or (b) Use a system library.  The developer calls the library and gets back a token.  No messing around with passwords, keyrings, confirmation Web pages … all that’s handled by the system service.

The developer thinks, “Perfect!  Problem solved and we’re being a good desktop citizen because the user only has to enter their password once.”

(b) seems the obvious choice, right?

Then the developer learns that Ubuntu and most of its derivatives (Ubunten?) use Ubuntu Online Accounts (UOA).  The rest use GNOME Online Accounts (GOA).  UOA and GOA are not API/ABI compatible.

Suddenly (a) looks like an appealing prospect.

This is a poisonous situation for application developers.  It’s not terribly visionary of me to suggest that the number of programs that interact with Internet services — the magical “cloud” — is only going to grow over time.  GNOME and Ubuntu are both acutely interested in attracting more developers (or at least should be).  But new and curious developers arrive and are confronted with this situation.

I speak from experience.  Both Shotwell and Geary could use some kind of Online Account solution today.  Canonical has forked Shotwell to call UOA rather than our handrolled code, but those patches have not migrated upstream, nor could we take them as-is.  Requiring UOA would preclude Shotwell from running on non-Ubunten distros.

I’m not here to argue UOA vs. GOA, or GNOME Shell vs. Unity, or lament that there’s yet-another split on the desktop.  I accept that both sides have decided to go their own ways (here’s Debarshi Ray giving his reasons).  But we at Yorba want Shotwell and Geary to work well — no, work spectacularly — on all GNOME desktops.  That we can’t deal fluidly with something as low-level as server credentials seems absurd.

I once had a professor tell me, “All problems in computer science are solved with a layer of indirection.”  He was being snarky, but there’s a germ of wisdom in that observation.  It seems to me that the solution to the GOA/UOA divide could be solved with a translation or wrapper library.  I’m not thrilled about wrapper code, but sometimes that’s what you’ve got to use.

To throw the first dart at the dartboard, here’s my proposed interface for such a library:

  • Enumerate supported Internet services: Facebook, Yahoo!, Google, etc.
  • Query a particular service for details/capabilities/description/icon/etc.
  • Generate an authentication token for a particular service
  • Launch the login/account registration application (i.e. the GOA/UOA program that takes the user though the steps of logging in to a service and making it available to all applications)

Obviously it’s far more complicated than this, but that’s the gist.  I know GOA is DBus-based, and I believe UOA is as well, so the solution could simply be a DBus interface that both technologies implement, perhaps in the org.freedesktop namespace.  In fact, maybe this should be a initiative.

We need something.  Asking an application developer (including Yorba) to pick UOA or GOA is a non-starter.  There seems to be a bit of bad blood between the GOA and UOA camps — I don’t know all the details — but I ask both of you to scratch together a bridge rather than fork the path.

Stirring the pond

Copyright Robin Webster (CC BY-SA 2.0)

If you’ve ever submitted a ticket to Yorba, you probably received an email from our Redmine server some time in the last week or so.  I’ve been going through each Shotwell and Geary bug one-by-one in an attempt to circumscribe the rather large, rather muddy pond they’ve grown into.  Each alteration and classification I made triggered emails to the original reporter, the maintainers, commenters, and more.  Thanks for your patience with us.

When I first waded into the ticket pond, Shotwell had something like 980 tickets; Geary, 390.  (I didn’t take notes throughout this process so I don’t have exact figures.)  Today the Shotwell pond is down to 898 tickets; Geary, 363.  That’s a modest 8% reduction, and I haven’t finished the job.  Most of that reduction is from closing duplicate and invalid tickets.  Some were the result of making hard choices.

If you’re a maintainer of an open source project with a large and steadily growing ticket database, I’d like to share what I learned the hard way this week:

Your tickets describe a possible future.  When you leave a ticket open, you’re saying, “Yep, this is something we’d like to do.”  If you’re not planning to fulfill a ticket, close it.  One unneeded ticket just further pollutes an already muddy and large pond and makes more work for you.  A key question to ask yourself is, Does fulfilling this ticket fit into the future we see (or want) for our program?

Watch out for tickets you “kind of” or “might” want to do.  If you use weasel-words to describe your interest in a ticket, that’s a red flag.  Don’t open placeholder tickets either — do you want to do this or not?

Another important question is, If someone submitted a patch for this, would we land it?  You don’t want to open a ticket and then reject a patch someone spent their precious weekends putting together because — whoops! — you don’t want that ugly feature after all.

You might be lukewarm about a ticket and think, “Hey, if someone does the heavy lifting for us, we’ll land their code, no problem!”  Remember: if you take a patch, you’re taking responsibility for that code.  Code you’re “okay” with today could be a nightmare tomorrow, and users don’t like it when features vanish.

Be bold.  Wikipedia’s motto is one of the best pieces of advice given on the Internet, period.  You can’t please everyone, and what’s more, you won’t, so wield an axe when triaging tickets.  Jeff Atwood talks about not letting your users convince you to build a truck when you’re building a car — good advice, especially since they might actually want a car.  Ticket triage is a lot like emergency room triage: each patient is important, but when there’s 980 of them, you turn away the toothaches (which, if you think about it, shouldn’t be in an emergency room).  It’s tough to drop a ticket because there’s always that nagging feeling that maybe we should keep this around…  Remember there are ramifications for keeping a ticket open, as I mentioned already.  Be bold.

… but not too bold. One ticket I thought did not describe the right approach to a problem.  A little push-back from users and a little more digging on my part revealed I’d made a false assumption.  Being bold doesn’t mean not listening or skipping investigation.  Don’t assume a bug’s gone away just because no one’s reported it in a while.  You can’t thoroughly test every case, but at least have some justification beyond inconvenience.

Look for jumping-off points into the pond.  Nine-hundred eighty tickets is a lot of tickets to slog through.  I decided to break down the Shotwell tickets into categories to open up some alternate ways to divvy up the problem.  To date I’ve only categorized about half of the tickets, but even that much was worth it.

The first obstacle I faced was defining “category”.  My first inclination was to think of subsystems as categories.  Soon I realized that associating a bazillion tickets by code location doesn’t really give you the perspective you need.  I decided to concieve of our apps as solving various tasks (“workflow”) and categorize that direction.  For Shotwell (a digital photo manager) I created categories like “camera” (i.e. hardware interaction), “raw”, “import”, “metadata”, “editing”, and so forth.  (If this was the 90s, I’m sure “printing” would’ve made the list.  Today it’s “web-sharing”.)  Not only did this help my immediate problem, it’s also more intuitive for the user who has to pick one when reporting a problem — compare to a user facing such intutive choices as “async” and “cairo”.  I’m still shaking out the categories thing — but again I say, be bold.

All kinds of magic happens with good categories.  Duplicate tickets popped up like flowers in the snow.  Inter-related tickets (potentially solved at the same time) suddenly seemed obvious.  What’s more, obscured problem areas jump out.  Our users are complaining about Shotwell’s duplicate detection (which prevents importing identical files) at various points in the application.  Each ticket was a nit and a theory about the best way to work around it.  Stepping back from them as a whole, I realized these tickets described a broader problem that we should solve as a whole, not in piece-parts.  If we hacked through the tickets one-by-one, we would’ve added a lot of workarounds and unrelated features, creating code complexity and an inconsistent user experience.

One word: Need Information.  A number of the tickets’ comment trails ended with asking the reporter for more information and never hearing back.  Some of these queries were years old, and without that information we legitimately couldn’t move forward to fix the problem.  These tickets I marked as “Need Information” and added a brief comment asking if the reporter could get back to us.  Thanks to email notification some of them did respond, even years after the fact.  Like not leaving open tickets you don’t plan on fixing, no reason to leave tickets open you legitimately can’t fix.  I plan on reviewing the remaining Need Information tickets a few months from now.  If they’re still blocked or unanswered, it may mean it’s time to close.

Stir the pond every so often.  It took a chunk of time, but I feel like we now have a better grasp of the problems we’re really facing, which means getting the changes our users want to them sooner.  This whole exercise took time, but I’m glad I did it.  What’s more, I think it’s something that should happen at regular intervals — every six months, maybe once a year.  Stirring through all the tickets is a good way to sift through the water a bit and see what’s lurking beneath the surface.

Shotwell 0.13.1 released for Ubuntu 12.10 on our PPA

Good afternoon, one and all,

In response to popular demand, we’re pleased to announce the presence of Shotwell 0.13.1 for Ubuntu Quantal users on our PPA. Among many other Shotwell-related tasks we’ve had to temporarily wait on, this has been one of the most-frequently requested ones, and we want to let you know that we haven’t forgotten about everyone who’d asked for this.

To add the PPA containing this build to your Ubuntu Quantal installation, simply do the following:
1) From the command line, type ‘sudo apt-add-repository ppa:yorba/ppa’ and supply your password as needed.
2) Type ‘sudo apt-get update’.
3) Type ‘sudo apt-get upgrade shotwell’.

Shotwell 0.13.1 Released!

Good afternoon, one and all,

We’re pleased to announce the release of Shotwell 0.13.1. We recommend that all users upgrade to this version.

Among the fixes in this release:

  • Increased robustness against server errors and malformed responses in the publishing subsystem
  • Better support for importing video from some Sony cameras
  • Correction of a problem where the searching and filtering UI could get out of sync with what was being displayed in a user’s library
  • Fixing of a regression in which the Send To feature didn’t work correctly with multiple photos

A tarball of this release can be obtained from, and Ubuntu users on Precise Pangolin can obtain a pre-built version from the Yorba PPA; users on Quantal Quetzal or other distributions should have access to pre-built binaries soon through the normal update mechanisms.

Again, thank you for your interest in Shotwell, and if you have any questions or comments, please feel free to let us know or mention them on our mailing list.