Observe, IIRC the videothumbnails directory is not just a cache. If I choose to assign a custom image as the static one in the thumbnailview, then it is also written into that directory.

Talking to one of the dolphin maintainers during Akademy showed that there's no need to involve baloo in this: filesystem tags are stored as extended attributes to the filesystem. If the extended attributes are enough for our needs, the easiest way is to use them: https://www.freedesktop.org/wiki/CommonExtendedAttributes/

Remaining files were resolved during Akademy. Translations remain a problem, but this can only be resolved elsewhere...

The untagged category/untagged tag part is implemented now.

I do use the privacy settings, though: there are photographs that I simply don't want to accidentally show to my in-laws, for example.
To maximize the usefulness of the feature though, I would try to make it more accessible to the average user. E.g. tie it to a specific tag or so. Currently, there's no way to really inspect the feature - you lock a set of photos away but afterwards you need to remember the criteria. Changing the set of "locked" photos (or rather the search expression) is not supported - you have to unlock, then select the new set, and lock again.

About the "Privacy settings": I would simply remove this. No "real" privacy as the photos are readable anyway, unresolved issues … I'm not sure if this is a feature we really need. If somebody has photos that shouln't show up in a search, I'd create another database rather than trying to hide them through some setting.

For now, kpa-thumbnails is good enough. (It can always be improved later, though).

REUSE compliance is 98% there (905 of 922 files). The remaining files have authorship information, but I could not reach their contributors for license information.

Related Bug:

• https://bugs.kde.org/show_bug.cgi?id=418325 (No diagnostic message if thumbnail files are not readable)

Relevant:

• https://phabricator.kde.org/T12930

Setting this to low because I want to be further in the refactoring before tackling this.

I'm not seeing this issue getting worked on any time soon. I don't think this will be fixed at all if nobody steps up.

I've registered KPhotoAlbum with the REUSE booster initiative. They are currently in contact with me, so maybe I'll get the remaining issues sorted out soonish. This is not a blocker for the next release, though.

Wall of text was removed in favor of more automatic behaviour.

I'm not sure that there is a really good way to do this. One other possibility would be a GUID, with XDG_CONFIG_DIR/kphotoalbumrc containing a mapping. That would also allow (if someone really wanted to do it) multiple configurations pointing to the same image collection.

Affected bugs:
https://bugs.kde.org/show_bug.cgi?id=448862

Implemented by https://phabricator.kde.org/T14825

Option --vacuum is now working.

Two core libraries (kpabase, kpathumbnails) have been created.

Video thumbnails are stored using the source resolution anyways, so problem there.
As far as video thumbnail performance is concerned, this is really a different topic for a different time.

So far, statistics and sanity checks are working, as well as an option to convert to the cache format used up to kphotoalbum 5.6.1.

This is possible with 04a3d5e881368111983003ba32d29e1871eebc80. There's now only a single place to define stylesheet information in the application, and the user can override the builtin style.

Going back to commit 862181b04 it seems that no problems have appeared from having analyzeduration in the frame extraction code.

As of 03114dbe0dd628b8f2060f38d295a93dd95497b2, KIPI support is officially removed from KPhotoAlbum.

This is implemented with commit 33838e72.

Both GThumb and Shotwell use the ‘stack of photos’ metaphor:

VDG: Did something come out of this? I know, "photo management" as a concept is hard to visualize. If you need input from me, please don't hesitate to ask ;-)