Thanks for all the discussion on this thread about Shotwell and filesystem paths. It's great to see how different users are using (and want to use) Shotwell!
I completely agree that one size does not fit all. Some users don't care at all about filesystem paths: they simply want to import their photos into a library directory and then work with them using a photo program that lets them forget about where they are all stored physically. Other users do care, however: they want control over where photos are placed and may have large existing photo collections which they have organized into folders manually. Both of these viewpoints are reasonable. Today, however, Shotwell only really works well for users who don't care where their files are, since it uses a fixed directory pattern at import time and since it doesn't expose photos' physical locations through the user interface. We plan to evolve Shotwell so that it can make both kinds of users happy. One step in that direction is letting the user choose a file naming pattern (http://trac.yorba.org/ticket/1597) to be used at import time, which we're hoping to implement in 0.8. We'd also like to implement a directory folder tree in the sidebar which you can use to browse through photos in their physical locations (http://trac.yorba.org/ticket/1594). With that, a user like Brian should be happy, I think: when using that tree, moving a photo from folder to folder will actually move it on the filesystem, and renaming a sidebar item will rename the directory. This would make Shotwell behave a lot more like gThumb. We could provide an option to display either the classic event tree or a folder tree as the user prefers. I know that many users would also like to be able to drag photos to applications other than Nautilus, as suggested in this thread. The reason we can't do that today is that Shotwell doesn't currently keep up-to-date full-resolution photos on hard disk, and it's hard to generate these on the fly at drag-and-drop time due to the way that GTK drag and drop works. The solution is to (optionally) have Shotwell generate full-resolution copies on disk after every edit (http://trac.yorba.org/ticket/1798). That will use more disk space, but will make drag and drop to applications work. One final thought: we agree that it would be great if Shotwell could store more of its state along with photo files so that they can be seamlessly shared among photo applications (but still cache it in a SQLite database for fast access, presumably). One big step in that direction is storing metadata in photo files on the fly (http://trac.yorba.org/ticket/1290). adam On 08/27/2010 07:34 AM, Lu Timdale wrote: > I think we can agree that one size does not fit all. > > This applies for > 1. Storage of the new files in whatever file naming pattern chosen by the > user > (exif> filesystem/sqlite) > [I believe this is coming in 0.8] > or > 2. Organizing existing files in library to match that pattern (exif/sqlite> > filesystem) > or > 3. Extracting parameters (event name, etc.) based on filesystem info > (filesystem> sqlite/exif) > > I don't see this as a problem, if it is done as optional approach based on a > checkbox or two. > > It doesn't mean that the default can't be whatever the yorba team sees as the > most used scenario. Currently I see this as point 1 only. > > Howeer, keep in mind that even iTunes has a setting to "keep my music > organized" > or "let me organize it myself". I believe in their case, it applies for all > music, not just new. > > > I am desperately waiting on 1 before I can switch over to use shotwell. > I personally would also see value in 2 and 3. > 2) I have changed my mind about how I want the files organized every few > years. So there are slight variations on the structure of the files. It is > virtually impossible to restructure the old content manually. This will never > change unless it's automated. > 3) My existing photo library (about 12 years / 200GB) have event name info > embedded in the folder names and/or filenames. It would be good if I didn't > have to redo all this work and it could be imported into Shotwell... the best > photo management app. :-) It is again virutally impossible to do this > manually. > > > > 2& 3 can be somewhat alleviated by allowing file system view of the folders > that have been added to the library. > > > I believe the real intent of this topic is that if a user WANTS all 3 sources > of > data (exif/sqlite/filesystem) to be in sync, he/she should have that option > avaiable to them. > > Just my 2 cents. :-) > > > > Lu Timdale > lutimd...@yahoo.com > > > _______________________________________________ > Shotwell mailing list > Shotwell@lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > _______________________________________________ Shotwell mailing list Shotwell@lists.yorba.org http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
