[KPhotoAlbum] Breaking changes in file layout

Johannes Zarl-Zierl johannes at zarl-zierl.at
Mon Apr 6 00:06:02 BST 2020


Am Montag, 6. April 2020, 00:22:30 CEST schrieb Robert Krawitz:
> 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:
> >> 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.

I guess I can live with that. From a scripting point of view it still is a 
one-way trip, though.

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

CategoryImages has much worse problems. Apart from renaming tags being a 
brittle operation, the only characters being escaped are space and slash. I'm 
kind of surprised that we didn't get any bug reports on this feature yet.
(E.g. I'm using ':' as part of some tag names, albeit obviously not for tags 
that I set a CategoryImage for).

While we're at it, maybe we should put some scrutiny on CategoryImages as 
well...

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

Currently, this can be an arbitrary ImageSearchInfo. I'm not opposed to 
simplifying this towards your approach, though.

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

You're right. My train of thought was that those settings should really be 
synced between different users accessing the database to prevent 
inconsistencies.
Maybe we could improve sync-ability of configuration by moving per-database 
configuration settings into their own config file.

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

It determines whether the untagged tag is shown as a normal tag or is hidden 
from the viewer.

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

Actually, I didn't mean to remove the user choice. I just think that linking 
that user choice for the current database with a general option does not make 
much sense.
I.e. there should be a (hidden) config option defining the default, but for 
any existing database, kphotoalbum should just use the existing format and if 
the user toggles the format in the settings dialog the format for that 
specific database is changed.

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

Ok. Seems plausible...

Cheers,
  Johannes




More information about the Kphotoalbum mailing list