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