[KPhotoAlbum] Auxiliary files, again

[Robert Krawitz]

On Sat, 6 Apr 2019 19:43:39 +0200, Johannes Zarl-Zierl wrote:
> 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

Allow the user to specify what to look for, using a list of suffixes.
We could provide some by default, or just allow the user to specify.
The list might look something like

.pp3;.xpp

etc.

We do nothing with the sidecar files beyond indexing them and
associating them with their parent image(s).

The associated file for a .pto (Hugin) file would be the associated
panorama, not the images comprising it.

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

My thought would be that it inherits, with no other option.  Perhaps
from the topmost image of the stack (if there's a stack).

> 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 was thinking mostly for import/export, but you're right -- it would
be very useful to be able to launch a .pto file, for exmaple.

>  I can see your point and that this can be a big improvement for kphotoalbum, albeit one that is not trivial to implement properly.

Yes; you've raised some issues here that I haven't thought about.

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

I don't think that's unfair.  We clearly have some more thinking to do
about this, and paying down technical debt isn't a bad idea.  For
example, today when I was indexing some photos kpa crashed on me
(something video-related, but I didn't have a chance to chase it
down), and there was no autosave file, so I lost some work (not a huge
amount, maybe 20 minutes).
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton