On Fri, Aug 27, 2010 at 04:03:54PM +0300, Mattias Põldaru wrote: > You are absolutely right here. Your workflow as described here, quite > doesn't need photo management program. As didn't mine, but I dumped it > in favor of better (shotwell) way. I right now don't see why you want to > keep doing it the old way.
I did try changing; indeed, I tried when F-spot replaced gthumb in Ubuntu. But it turns out to make life a lot more difficult. Use cases: 1. My wife (who logs in as a different account on our PC) wants to be able to locate a photo I took, to mail to her friend. Currently she has to browse down the filesystem hierarchy YYYY/MM/DD to find it. It's painful. I suppose she might be able to run shotwell with the -d flag to point to my sqlite3 database, which she would have read-only perms on. She doesn't know anything about using the command line, and doesn't want to learn. Furthermore, I don't think she'd be able to drag-and-drop the photo from Shotwell into Thunderbird anyway, so would still need to traverse the filesystem. (*) 2. I sync parts of my home directory between my laptop and desktop using unison, partly so I have local access to the files, and partly as a form of backup. I would like to do tagging and organising at both sides. I could try syncing the .shotwell/data/photo.db file, but if I ever made changes at both ends, they would be in conflict and the database couldn't replicate. Renaming a file does cause it to be treated as delete-and-copy by unison, but at least it's a non-conflicting operation. 3. If I get a new TV with DLNA, or a network-attached media player, I'd like to be able to browse my photos on it. I'm guessing I'll only be able to browse by folder. Again, it would then become hard to find a specific photo or event if it's under YYYY/MM/DD. Now, some of these issues would go away if the events were stored in EXIF. For example: my wife could import my photo library into her own collection (which could be another instance of shotwell, with its own database) and still see my events and tags, as long as shotwell refreshed itself on changes. Replication wouldn't be a problem - or at least, if a replication conflict occured, it would be for a single photo rather than the whole database, so would easily be resolved. Some of these issues might also go away if shotwell used a distributed replicating database like couchdb, although that introduces platform dependencies and its own conflict management headaches. But at the end of the day, the reason I want to organise under YYYY/EVENT is because it just makes life so much easier to locate a photo externally to the photo app. Call me old-fashioned if you like. > Also, it would be nice, if you developed an export plugin for shotwell, > which exports all photos into folders, named year/mo/event/day. HH:MM > Title.jpg, so you could backup all files and have these organised well > for off-shotwell usage. Why exporting, not external scripts? So you can > let shotwell apply all the adjustments you have done to photos (color > enchancements, cropping etc). That would work, and might be the best approach for the media-player/NAS scenario, at the cost of doubling disk space. Regards, Brian. (*) Possibly we could set up a shared photo library and a shared .shotwell directory - that would require appropriate use of Unix group permissions with setgid bits on directories etc. Life is too short to debug the fallout from that :-) _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
