Re: Auxiliary files, again

Hi,
Am Donnerstag, 4. April 2019, 02:34:08 CEST schrieb Robert Krawitz:
> > I think as you describe the use-case, stacks are really an
> > orthogonal concept.
> 
> Well, the idea is that they're associated with one (or a group of)
> photos.  The way I use stacks, at any rate, is to stack all images
> that are the same shot or a direct derivative; in that light, the
> sidecar files are similar.

Ok.

> > Just checking with one .xmp I picked randomly, it seems that the
> > filename is stored there. I don't know whether this is required for
> > xmp files, and how it is for different sidecar formats.
> 
> It's not for .pp3 files (just checked).

Thanks for checking...

> Perhaps, but I want to make sure that any copy/import/export operation
> has the ability to include sidecar files of the user's definition
> (there's no reason they have to be restricted to specific known
> varieties; darktable, hugin, and rawtherapee are surely not the only
> things that have sidecar metadata).  That would argue for them to be
> first class objects.  They aren't actually images, to be sure, but
> they are representations of images.

So this begs the questions:

1. What kind of sidecar files are there, and which ones do we want to support?
Note: Most file types would be 1:n, though with hugin or other panorama files 
we would have a n:m relation

2. Does a sidecar inherit the tagging data of the associated image(s) or does 
it need separate tags?

3. I guess that just displaying a list of sidecar files is not enough to work 
with them in a meaningful way? If not, I guess we need to allow for some kind 
of extension mechanism to render and interact with the files.
 
I can see your point and that this can be a big improvement for kphotoalbum, 
albeit one that is not trivial to implement properly.

I do like to continue this discussion, but I guess it's fair to add a 
disclaimer:
My gut reaction would be "can we postpone this until we have a testing suite", 
but that would be unfair to you. Right now, for me the biggest priority is to 
reduce our technical debt and get a clean boundary between UI and non-UI code.

Cheers,
  Johannes