I swear, some day I will learn to copy the list on responses.... > > 1. Importing the photos with no EXIF timestamps with the "copy" option > reads the photo for metadata _after_ the copy - this hoses the mtimes, > and leaves me with a thousand photos "taken" today. This is fixed by > passing both the new/destination and old/source path (which can be > identical if a copy was not performed) to PhotoStore.Create. It will > parse the data from the old/source path and do everything else on the > new/dest path. Makes me happy ;)
That is a great idea. I ran into this as well recently. > > 2. Respect the DragAction for DnD files from Nautilus to F-Spot for > importing. If you effectively DnD with the Gdk.DragAction.Copy flag, the > photos will be copied and imported. If you drag with > Gdk.DragAction.Move, they will not be copied. > > This modifies the default behavior: DnD with no key modifiers will copy > and import. You have to hold "Shift" and DnD to not copy. Since this > changes the current default behavior, maybe this needs to be discussed. > I think it's sane however since the Move/Copy is set from Nautilus, and > is how Nautilus itself works. (The previous functionality of this I > think is *incorrect*. I always assumed F-Spot copied my photos when I > had the copy modifier set for the drag. > One comment on this. I understand that the copy modifier would copy it, but the move modifier not to copy it doesn't make much sense. I would actually expect the move modifier to copy them into f-spot's file structure and remove them from where they are. Might be useful for importing from a camer and cleaning off the camera in one ( nerve wracking ) step. In order to get the import but don't copy feature, maybe the link modifier would be more intuitive. John _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
