[Shotwell] Shotwell reviewed in LWN

[Adam Dingle]

On 06/16/2010 11:56 PM, Sebastian Spaeth wrote:
> Dear all, I am new here. Hello!
>
> I wanted to point you to a quick grumpy editors review of shotwell:
>
> http://lwn.net/SubscriberLink/392261/b6d9e95899253392/
>
> I am sure you have a couple of comments or trac tickets to respond :-).
>    

Sebastian,

thanks for the link to the LWN review!  FYI I just posted a response on 
that page, which I'll also include here:

===

Grumpy Editor,

I'm the founder of Yorba (makers of Shotwell) and have been deeply 
involved in Shotwell's design from day one. Thanks a lot for trying out 
Shotwell and for the candid and thorough review. We always appreciate 
direct feedback and are happy to hear about what people do and do not like.

Grumpy Editor, your review touched on various points about Shotwell, but 
of course your biggest gripe was about the way Shotwell imports photos 
and about the relationship between the Shotwell photo library and the 
file system. I'll first provide brief feedback about some of the smaller 
points:

- You mentioned the lack of support for RAW photos and zooming into 
photos. Both of these features have been impemented in trunk and will be 
present in the Shotwell 0.6 release (coming in the next two weeks).

- As someone else pointed out in another comment, it actually is 
possible to split an event apart in Shotwell: simply select the photos 
you'd like to split into a separate event, then choose Events->New Event.

- It actually is possible to remove a tag from several photos at once. 
Simply select the tag in the sidebar, then select the photos you'd like 
to remove it from and choose Tags->Remove Tags From Photos.

- We do hope to implement hierarchical tags at some point (that's 
http://trac.yorba.org/ticket/1401, if you're curious).

OK, and now on to your Major Concern. As you pointed out in your review, 
Shotwell expects you to import all photos into its library. As you do 
so, Shotwell indexes their metadata so you can search them in various 
ways. You can edit photos in Shotwell, but normally your changes stay in 
the Shotwell universe. Changes get written to files only when you export 
(or, in Shotwell 0.6, when you use Shotwell's Open in External Editor 
command, which writes pending changes to a file and then opens an 
external program such as GIMP on it).

The Shotwell model is common among commercial photo programs; iPhoto, 
Aperture and (to some degree) Picasa all work this way, for instance. 
But clearly you want a photo program to use a different model. You'd 
like to be able to browse through photos easily according to their 
on-disk file hierarchy, and presumably you'd like photo edits and 
metadata to be stored in the photo files themselves, at all times. I 
imagine you'd also like to be able to search for all photos matching a 
given tag or in a given date range. For this to be possible, a photo 
program must of course index the on-disk photos, which is itself a form 
of importing, really. But it sounds like you're opposed to an explicit 
import step. (Perhaps you'd like to point a photo program at your 
top-level photo directory and let it index everything in the background. 
Or maybe you'd like a photo program to automatically index all the 
photos in directories which the user browses through.)

So, then, which model is superior? We built Shotwell to use explicit 
importing and to store edits in its own database both because other 
popular programs work that way and because certain users have told us 
they want us never to touch their originals (see, for example, the 
discussion at 
http://lists.yorba.org/pipermail/shotwell/2010-April/0002... 
<http://lists.yorba.org/pipermail/shotwell/2010-April/000283.html>). But 
recently we've been getting more and more feedback from people like you 
who want a storage model based directly on the filesystem (see, for 
example, http://ubuntuforums.org/showthread.php?p=9475456 or 
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/5... 
<https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/579808>). So 
I've actually become less and less sure that we've gotten this right, 
and I think it's likely that we'll switch to something like your 
preferred storage model in a not-too-distant release, at least as an 
option for the user. In fact, different users seem to have distinctly 
different storage preferences, and so perhaps we can even evolve 
Shotwell to the point where the user can choose where data is stored. 
For example, a user might want us to store metadata (e.g. photo 
titles/keywords) either in the original files, in sidecar XMP files, in 
the Shotwell database, or in Tracker. It might be cool if Shotwell could 
do any of these as you please.

As you mentioned, Shotwell is a young utility. We do in fact plan to 
evolve it to work more flexibly together with other Linux tools, so 
thanks again for the feedback and please keep your eyes open for future 
Shotwell developments!

Cheers,
adam

===