* Stéphane Gourichon <[email protected]> [11-21-16 12:21]: > Le 20/11/2016 à 19:24, Tobias Ellinghaus a écrit : > > > > That is not feasible as we rewrite the XMP files all the time. Not just when > > you edit the image in darkroom. > > IMHO this behavior pops up too regularly in discussions. > > > # Context: user feedback + usual reply > > This is from memory, I might be wrong. > > User: "darktable (writes an uninteresting XMP file | clobbers interesting > XMP file) for *each and any* raw or jpeg file that it encounters at startup. > This (slows down|clutters directories|loses minor information|loses > important work|feels wrong)." > > Reply (from memory): (due to the way we organized things|we just write XMP > at some points in time and which causes overall behavior just like you > wrote|it's too difficult to change that behavior|just remove them if > undesired|make dir read-only) > > Spirit of Free Software whispers : "Use the source Luke." > > > # Zooming out to get the big picture > > From an outside perspective, current behavior still doesn't feel right. > > From a functional point of view, there's no good reason to write a XMP file > for a file that was not even opened in darkroom. > > Sure, darktable has default processing options, and might use them to > display thumbnails (in some configurations). > But by definition these options are *generated defaults*, so there's no > point in saving them. > Saving them "pins" those default to the particular version of darktable just > run, is there added value ever in that? > > > # Related information > > Does current code causes an inclination for bugs like this one? Bug #10012: > Darktable overwrites existing XMP files > <https://redmine.darktable.org/issues/10012> > > Also, option write_sidecar_files is not the wished behavior, as XMP files > are definitely useful when they contain not only generated information, cf. > 8.2. Core options | user manual | darktable > <http://www.darktable.org/usermanual/ch08s02.html.php> > > > # Guessing an implementation > > Quick look at ./src/common/image.c void dt_image_write_sidecar_file(int > imgid): > > > // TODO: compute hash and don't write if not needed! > > Darktable *already features some tags "changed" and "exported"* in database, > searchable with the "collect images" structures filtering module. > > Given the expected semantic of a "changed" tag, it looks efficient, simple > and natural to write something like: > > if ( (no XMP file already exists) && (image has no tag "changed") ) { skip > xmp creation }; > > That way, XMP indeed gets created when relevant. > > > # Benefit and conclusion > > Current implementations feels like darktable has "dirty hands" or goes "like > a snail/slob/slug": wherever it goes you see its trails that you have to > clean if they're undesired. > > * With new behavior, user can open in darktable any dir (USB key from a > friend, whatever) and not clutter it. > * Only edited pictures (if any) will get a sidecar file, which makes it > easier to spot them e.g. for copy-paste back in external file manager. > * Opening wrong directory will not clutter it. > > All those use case happened to me. I'm not covering all cases for the sake > of brevity, but I don't get why this was not approved earlier. > > (1) Can a fellow savvy darktable wizard elaborate/explain? > > (2) If someone offered a clean patch performing this exact change "just > opening a file does not create a XMP, an edit causes it", would you merge > it? If not, can you explain the rationale? >
there is an option to "write sidecar file for each image". turn it "off". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
