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
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