Brian, the advantages of the present system are that the logical view of your photos (events/tags/ratings etc) is completely decoupled from the physical storage of your photos. This means each person can store their photos as they see fit and that Shotwell does not dictate this to you. It also means that you can change your storage model without breaking your logical model (when, as planned, Shotwell detects changes to file layout). We are conditioned into thinking of our physical layout as being equivalent to our logical layout. This is the consequence of using file manager tools to organise our photos. But tools like Shotwell allow us to break free from the constraints of a physical storage model. So for example you can combine or create new events without touching your physical layout. This is especially evident once you start making extensive uses of tags to create new views of your data. Tying the logical model of your data to the physical model creates more problems than it solves and greatly reduces flexibility. Peter
On Fri, Aug 27, 2010 at 11:31 AM, Brian Candler <[email protected]> wrote: > (I was going to add this to ticket 1290, but then thought it would be > better > to discuss it on the list first) > > I'd like to note that another possible place to store (some) metadata is > within the filesystem path. Specifically, I like to organise my photos as > %YYYY%/%EVENT%/%FILENAME%; with this model, the event can be inferred > directly from the path. > > This has some knock-on effects though: > * If I rename an event, it should rename the directory > * If I change the event of a picture, it should be moved on the filesystem > * There are some possible ambiguities, e.g. 2008/Christmas and > 2009/Christmas > * Either the event name should not be allowed to contain a slash, or an > event containing slashes maps to nested folders (which makes renames more > complex) > * It could be awkward to keep track of the other shotwell metadata linked > to a picture if they are moved around externally > > The benefit is that if I have already organised my photos this way, or > decide to reorganise them using drag-and-drop at the filesystem level, this > could be immediately reflected in the application. It also gives a good > way > to browse photos in dumb media players. > > It's probably only useful for event though. It wouldn't work for any > multi-valued attribute, like tags, without getting messy (e.g. if a tag is > a directory containing symlinks to the photos) > > I also found ticket 1597, but I think the suggestion here is different. > #1597 is about choosing the location to copy a file into the library > initially, whereas I'm suggesting that the location be used to hold the > current value of the event attribute - so changes to event are reflected in > filesystem, and vice versa. > > Comments? > > Brian. > _______________________________________________ > Shotwell mailing list > [email protected] > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
