Hi again,

Good news / bad news:

On 2018-03-12 13:33, Jens Georg wrote:
>> I have had write-back enabled in the past - but not now. I disabled it
>> a couple of weeks ago (and removed all tag-information from my photos)
>> in an attempt to get rid of the tag-problem.
>>> Please provide a debug log of all those things if you can reproduce
>>> them easily.

I installed Visual Studio Code today and to my surprise, debugging Vala works to some degree. One can at least step through the Vala code, although inspection of variables are... well 90% not working.

But it means that if I encounter some of the other bugs (not the one I mention next) I might be able to debug a little bit :-)

Another set of good news / bad news. I found out the source of one of my problems today - the re-appearing tags.

Turns out that even-though I had removed tags from my image files, some of the _modified-files still had that information. I know that Darktable will write those information, but I thought I had removed all information from DT as well.

But... At least right now, my tags seem to be in place and stable.

That kind of leads me to a change suggestion. Could the logic be so that if Write-back-to-image-files were *not* enabled, then Shotwell will only import metadata on actual image import, and not re-import metadata on start up?

I am sure there are lots of details in this that I am not aware of; but is this a good idea?

Argument behind the suggestion:
Data should ideally only reside in *one* place. If it is duplicated, one should be the Truth, and the other should only mirror that.

Hence, if write-back is not enabled, the database should be the truth, and metadata only imported on actual image import.

If write-back is enabled, then image files are the truth, and the database should always mirror this. I believe this is what the re-import of the metadata does at the moment.

shotwell-list mailing list

Reply via email to