Re: [darktable-user] look for updated xmp files on startup
> "And when the sidecar file > and the internal database actually disagree, then you have to figure > out which one is the definitive source of truth." > > That would be my question yes...how do you know which one to chose between > either updating the dbase or the xmp file..? It would depend on the reason for the disagreement. For example, if you have purposely modified the xmp file with an external editor, then you probably want to copy the xmp info over the database. But if you accidentally overwrote the xmp file with garbage, you probably want to copy the database info over the xmp. However, there are really few instances in which both would disagree. If you keep all your edition on darktable, the most probable reason for disagreement is xmp file corruption and non-updates because of power failure, and then the database should be the most accurate source. Regards, Guillermo darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] look for updated xmp files on startup
"And when the sidecar file and the internal database actually disagree, then you have to figure out which one is the definitive source of truth." That would be my question yes...how do you know which one to chose between either updating the dbase or the xmp file..? I find I have a hard time explaining myself in writing especially when I'm not conversant with the material causing me issues. On Tue, Mar 31, 2020 at 7:27 PM wrote: > Hi > > J. Verreault (2020-Mar-28, excerpt): > > Can someone help me with the bold part please...? > > DT stores the processing you do on an image in two places, an SQL > database, and an XML file. The database allows for fast searching in > a huge collection, and the files allow to organize (backup, copy, > send) your images using the usual operations an operating system > offers. Both ways have their (dis)advantages. Unfortunately, having > both introduces bad redundancy. (Redundancy is not always bad, e.g., > backups are good). This redundancy is bad, because every change has to > be recorded in both places consistently. And when the sidecar file > and the internal database actually disagree, then you have to figure > out which one is the definitive source of truth. The discrepancy > might arise from a crash or a bug, but also legitimately, e.g., > because an external tool or even DT has just modified one of them and > now you want to propagate the change to the other. That's when DT > needs to ask you. > > What precisely would be your question? > > > -- > https://stefan-klinger.de o/X > I prefer receiving plain text messages, not exceeding 32kB./\/ > \ > > > darktable user mailing list > to unsubscribe send a mail to > darktable-user+unsubscr...@lists.darktable.org > > -- You don't know what you have until you need it. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] look for updated xmp files on startup
Hi J. Verreault (2020-Mar-28, excerpt): > Can someone help me with the bold part please...? DT stores the processing you do on an image in two places, an SQL database, and an XML file. The database allows for fast searching in a huge collection, and the files allow to organize (backup, copy, send) your images using the usual operations an operating system offers. Both ways have their (dis)advantages. Unfortunately, having both introduces bad redundancy. (Redundancy is not always bad, e.g., backups are good). This redundancy is bad, because every change has to be recorded in both places consistently. And when the sidecar file and the internal database actually disagree, then you have to figure out which one is the definitive source of truth. The discrepancy might arise from a crash or a bug, but also legitimately, e.g., because an external tool or even DT has just modified one of them and now you want to propagate the change to the other. That's when DT needs to ask you. What precisely would be your question? -- https://stefan-klinger.de o/X I prefer receiving plain text messages, not exceeding 32kB./\/ \ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
Re: [darktable-user] undo collapse of panels in darkroom mode
On 3/30/20 6:58 PM, Patrick Shanahan wrote: * Ludger Bolmerg [03-30-20 12:52]: Hello I hid all panels in darkroom mode using letter 'b' as described in https://www.darktable.org/2019/12/darktable-30/ I can restore all panels as described in the article but when I restart darktable and switch to darkroom mode all panels are hidden again even if I leave darkroom with all panels shown. How can I revert to the standard behavior of darktable, i.e. all panels shown? Pressing letter 'b' again to restore the panels does not work. Is there an entry in darktablerc that I could change? I am on darktable 3.0.0 on FreeBSD first step would be to look into ~/.config/darktable/darktablerc collapse and visible would be key words. then TRUE and FALSE or 0 or 1 also, if current settings are not being retained in darktablerc, do you have it in a different location or are you starting dt from the cl with odd parameters? check the timestamp on darktablerc stat ~/.config/darktable/darktablerc should display an access time that you last closed dt. thanks Patrick after deleting a bunch of entries from ~/.config/darktable/darktablerc containing the strings 'collaps' or 'visible' in there name I am back to normal. Please don't ask me which of them was the culprit. darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
