[KPhotoAlbum] Breaking changes in file layout

Johannes Zarl-Zierl johannes at zarl-zierl.at
Sun Apr 5 22:50:29 BST 2020


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.

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

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

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


> > 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)
* HTML Settings (i.e. HTML exporter settings)
* Privacy Settings (i.e. which images should be hidden)

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.

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
* useExifRotate
* useExifComments
* stripExifComments
* commentsToStrip
* ignoreFileExtensions
* skipSymlinks
* skipRawIfOtherMatches
* compressBackup
* backupCount
* trust TimeStamps
* excludeDirectories


These settings seem noteworthy to me, but I currently think they are better of 
in kphotoalbumrc:

* untaggedImagesTagVisible
-> this is a user preference

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

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

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

Johannes





More information about the Kphotoalbum mailing list