Out of scope / create feature request on buzilla if desired.

-> Feature request on bugzilla

Nothing changed in the last 6 years.

-> bugzilla wishlist

If this still makes sense, recreate as feature request on bugzilla.

-> move to bugzilla

Closing because this should be tracked on bugzilla; no actual bugs have been filed so far.

-> move to feature request on bugzilla

Closing because this is tracked on bugzilla.

Closing because this is tracked on bugzilla.

Bugs are tracked on bugzilla; no need to duplicate this here....

After eight years, I think this is stale...

New tracking item: https://invent.kde.org/graphics/kphotoalbum/-/work_items/3

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.

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.

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

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

In T13198#259279, @lydia wrote:

Sounds fun. Wanna create a ticket for it on the 25th anniversary board?

Inspired by the "Desktop through the ages" task: it could also be nice to look at the lineage tree of the KDE desktop stack. I.e. which parts/technologies/apps begat other ones, which parts did we "lose"?, how far back can we trace existing apps? E.g. xpdf begat kpdf begat okular

Option --vacuum is now working.

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

Sorry I couldn't make it to the BoF so I don't know whether this idea was already discussed and dismissed:
Since board games are mentioned, how about something with a "Robo Rally"-like gameplay? Promoting KDE *and* potentially getting people familiar with programming basics would be a win-win...

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.