(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
