[Shotwell] Shotwell reviewed in LWN

David Velazquez david.velazquez08 at gmail.com
Fri Jun 18 16:01:43 PDT 2010


Adam, thanks for cross posting your comment here. My thoughts on the issue
of how Shotwell handles photomodification (it sounds like it boils down to
saving changes on the file system or it's own database) would be that users
would never be completely pleased and satisfied with how Shotwell handles it
no matter how many options there are.

Referencing the launchpad bug report, it sounds like either options A or B
would work for any person, it's just a matter of how well Shotwell would
work for them. Creating two different ways of doing what is essentially the
same thing seems complicated to me and may open up Shotwell to more
complicated and difficult bugs in the future, I think.

To me, a better approach might be to choose what user group, either amateurs
or professionals, Shotwell is geared towards and decide which way of saving
changes would work best for them based  on the comments received. I
understand this may be an unpopular post and completely against the way
Yorba might like to do things, but in my limited experience it isn't easy to
be a jack of all trades here. By all means though, if you decide that's your
goal I'm all for it!!

Just my thoughts on this.

Dave

On Thu, Jun 17, 2010 at 6:58 PM, Adam Dingle <adam at yorba.org> wrote:

> 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
>
> ===
>
> _______________________________________________
> Shotwell mailing list
> Shotwell at lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>



More information about the Shotwell mailing list