Response from Shotwell team founder

Posted Jun 18, 2010 0:42 UTC (Fri) by dlang (guest, #313)
In reply to: Response from Shotwell team founder by jspaleta
Parent article: A quick grumpy review of Shotwell

no, shotwell is like if git was integrated into gedit and you could only access the files through gedit.

git doesn't force you to use a specific tool to manipulate the working copy of the files stored in it.

if shotwell organized the images and left them alone in the filesystem for you to use whatever tool to tweak them, you would not see people raising this objection.

Response from Shotwell team founder

Posted Jun 18, 2010 13:21 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

Insightful comment there.

It follows from what you say that an equivalent model with Shotwell would be if the photos on disk were with modifications applied, with Shotwell keeping data somewhere on how to undo changes (or conversely how to change the original to the current version on disk). ?

Response from Shotwell team founder

Posted Jun 18, 2010 14:51 UTC (Fri) by adamdingle (guest, #67751) [Link] (2 responses)

I agree: it would make sense for Shotwell to store photos on disk with modifications applied, but with the original photo backed up under a separate filename and also storing information about how to change the original to the current version on disk. As some people have observed, it would even be nice if the transformation information could be shared among programs, not specific to one program such as Shotwell. Perhaps we can get there one day. We're interested in modifying Shotwell to use a GEGL pipeline and that might be one step toward a transformation structure that can be shared.

Response from Shotwell team founder

Posted Jun 18, 2010 18:52 UTC (Fri) by dlang (guest, #313) [Link]

that would be good. I don't think it's that necessary for the exact details of how to convert one to another be available cross application (other than as comments/documentation trail/changelog)

but the unmodified original should always be available (or recoverable, with with lossy compression algorithms means a copy), and the currently 'final' result should be accessable without a need to run some export process.

Response from Shotwell team founder

Posted Jun 19, 2010 2:42 UTC (Sat) by spitzak (guest, #4593) [Link]

Editing should just move the original from X/foo.jpg to X/originals/foo.jpg, and it should throw it away if that file is already there (thus you only keep the most recent edit and the original). If other applications followed this rule as well then you could use any editor and still recover the original.

I would very much like to see a photo manager that just leaves the files where they were. You would give it a list of directories and it will act like the set of photos is every photo found in those directorys and any subdirectories. If a file is in a given directory it acts like it has a tag that is the directory name, as well as any tags that are in the EXIF data. Attempting to remove these "directory tags" would, I guess, move the files, perhaps with a warning. Or add a "not actually tagged with this" tag.

For Linux apps this almost is necessary, just so you can cooperate with some of those proprietary apps that insist on moving the files. For instance I would like to use it to at least look at an rsync copy of a iPhoto directory. If we are careful we should be able to at least change the tags and perhaps edit files and those apps will still handle it.

There may be an "import" but it would be for reading off of cameras and SD cards and other removable media, where you have a good reason to want a copy. The user should be able to choose what directory it goes into, and there should be programmable scripts (with some pre-supplied ones) to use dates and other EXIF data to place the files into subdirectories.