On Wed, 2009-11-04 at 21:34 +0100, Aurélien Naldi wrote: > A while ago, I had a look at a branch for this. The patch was pretty > straightforward: remove all calls to the function responsible with > timestamp shifts. > If this branch has not yet been ported to the latest version, I hope > it is still simple enough to do it again. I may look at the existing patch myself, if it's fairly straightforward perhaps I can make some progress, although I'm not a C# coder, and barely even a C coder ;) > While someone else raise this concern again, I would like to re-ask > wether there is a chance for upstream f-spot to make it easier for the > people willing to keep their timestamps sane without loosing tags. > > A simple function, performing or not the timestamp shift depending on > an hidden gconf key would for example be lovely. It would be even > better if it could depend on the status of a checkbox in the import > dialog. I'd like this implemented as well. > Indeed, even if the current behaviour is a feature, it can not > possibly be right to shift timestamps each time a picture is imported > (I happened to drop my f-spot DB several times to test tag imports and > other new features in the past...) I've heard it argued that since you check the "Store metadata in the file" box, you're indicating that you want F-Spot to alter your metadata. However, my take on this is that a distinction should be made here: My intention, in telling F-Spot to store metadata in the files, is something along the lines of "Yes, please store the changes *I make* to the metadata (tags, *Manually adjusted* timestamps, etc) into the files. It was never my intention, as a user, to have F-Spot *automatically* adjust any metadata. I very much think that a separate and distinct permission should be granted for F-Spot to automatically adjust timestamps. I'm not sure how the developers feel on the issue, but to me it seems quite clear that there is a difference between writing user-initiated changes to the files, and automatically altering the files. > If such a patch has a chance to be accepted, I am willing to help with > the code, unless a better solution is in the work? > > Best regards. > Thanks for your input on this. It doesn't directly answer my questions, but it does bring up some good points. Regards, -- Steve McGrath smcgrath23 gmail com
Attachment:
signature.asc
Description: This is a digitally signed message part