[KPhotoAlbum] Breaking changes in file layout

Sun Apr 5 23:22:30 BST 2020

On Sun, 05 Apr 2020 23:50:29 +0200, Johannes Zarl-Zierl wrote:
> Am Sonntag, 5. April 2020, 22:49:32 CEST schrieb Robert Krawitz:
>> On Sun, 05 Apr 2020 21:48:30 +0200, Johannes Zarl-Zierl wrote:
>> > Therefore, I plan on restructuring the file hierarchy like this:
>> > DBDIR/index.xml
>> > DBDIR/CategoryImages
>> 
>> What's CategoryImages?  I don't have such a directory.
>
> You can assign images to tags - usually it is used to add the face
> to a person.

OK, something I haven't done.

>> One thing I'd like to think about is how kpa could work with multiple
>> users accessing a read-only collection of images.  That would mean at
>> least the ability to separate these files from the actual image
>> storage.
>
> Having a read-only database alongside a read-only collection of
> images shouldn't pose a problem with the proposed scheme.

I'm thinking a read/write database with read-only images.

>> > XDG_CACHE_DIR/kphotoalbum/<db>/exif-info.db
>> > XDG_CACHE_DIR/kphotoalbum/<db>/.thumbnails/
>> > XDG_CACHE_DIR/kphotoalbum/<db>/.videoThumbnails/
>> > XDG_DATA_DIR/kxmlgui5/kphotoalbum/kphotoalbumui.rc
>> > XDG_DATA_DIR/kphotoalbum/<db>/layout.dat
>> > XDG_CONFIG_DIR/kphotoalbumrc
>> > 
>> > The "<db>" part in these paths would be the md5 sum of
>> > DBDIR/index.xml (e.g. "echo -n /home/johannes/Pictures/index.xml |
>> > md5sum").
>> 
>> I hate hashes like that; it's impossible to reverse them to figure out
>> what they refer to.  I'd prefer some kind of fairly transparent
>> encoding of the path; maybe it could even be the path (which yes,
>> would mean the files might be nested somewhat deeply.  Or replace the
>> / with a | (which isn't often used in paths).  It doesn't have to be
>> perfect, just good enough to be distinguished.
>
> I get your point, but I'm not a big fan of constructs like "/home/
> johannes/.cache/kphotoalbum/home/johannes/Pictures" either.

Yeah, that's ugly; maybe if it were

/home/johannes/.cache/kphotoalbum/home|johannes|Pictures

or some such it would be easier.

> Maybe adding a symlink to index.xml or a file containing the path
> would be the best of both worlds?

Perhaps, but CategoryImages has the same problem.

>> > As was previously pointed out, some settings in kphotoalbumrc may
>> > also be better moved directly into the index.xml file (e.g. the
>> > "untagged category" info). I would propose making these changes at
>> > the same time...
>> 
>> I definitely think that everything that refers to the collection of
>> images be in the index.xml file (and out of the preferences dialog).
>
> That was my initial opinion as well, but I've come to think that not
> everything belongs into the index.xml file.
>
> Here is my current opinion, obviously open for discussion:
>
> These settings are already per database:
> * Thumbnails (= thumbnail size)

I agree that that doesn't belong in the index file.  Thumbnails are
not part of the index file; that's not part of the collection of
images per se.

> * HTML Settings (i.e. HTML exporter settings)

Likewise.

> * Privacy Settings (i.e. which images should be hidden)

I think that should be part of the index file.  That is a property of
the collection of images, and it's easy to see how it would be
represented:

<value value="H" id="8" hidden="true"/>

That would also allow multiple hidden tags, if someone wanted to do
that.

> Of those, only the privacy settings seem both database-specific and
> machine invariant. Having thumbnail size in the index.xml, but the
> thumbnails on local storage wouldn't make much sense. Having HTML
> exporter settings in the index.xml just seems plain wrong to me.

I think we're in accord on that.

> These settings are currently not database-specific but should IMO be part of index.xml:
> * Untagged Category
> -> this one is really annoying in its current state

This seems very similar to the privacy setting.

> * useExifRotate
> * useExifComments
> * stripExifComments
> * commentsToStrip
> * ignoreFileExtensions
> * skipSymlinks
> * skipRawIfOtherMatches
> * compressBackup
> * backupCount
> * trust TimeStamps
> * excludeDirectories

These are definitely per-database settings, in my view.  But they're
not part of the "collection of images" or related metadata, at least
in my view.

> These settings seem noteworthy to me, but I currently think they are better of in kphotoalbumrc:
>
> * untaggedImagesTagVisible
> -> this is a user preference

What exactly does this do?

> * load optimization settings
> -> performance settings are machine-specific

Well, they're actually storage-specific, and a database might have its
contents split across multiple drives with different characteristics
(on my laptop, part is on a SATA SSD and part is on a rotating disk).
How to handle that, we'll have to see.  But I don't think that that's
really part of the collection of images.

> * useCompressedIndexXml
> -> this should probably not be a setting at all. The UI should just show the current state and allow the user to convert to (un)compressed format.
> The setting can be kept as a way to set the default value for new databases.

I think I agree.  The uncompressed format is probably safer (it's
certainly easy to recover from problems), although IIRC we had a
problem that only hit uncompressed index files recently?

The big problem with the two formats is that it increases the testing
surface.

> * file version detection settings
> -> this is really user-specific, especially if one also uses the "open copy in different application" feature.

I think this is more per-database personally.  I can easily see use
cases where you want different collections of images to have different
file version detection and stacking behavior.
-- 
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