| Summary: | Feature to create photo albums (groups of photos) | ||
|---|---|---|---|
| Product: | [Applications] Koko | Reporter: | Jack Hill <jackhill3103> |
| Component: | General | Assignee: | Unassigned bugs <unassigned-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | nate |
| Priority: | NOR | ||
| Version First Reported In: | 23.04.1 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Jack Hill
2023-05-24 10:28:57 UTC
I have a significant concern here: overlaying a non-filesystem-based organizational structure on top of the underlying filesystem-based organizational structure contributes to vendor lock-in. If you ever want to use a different app, you lose your photo organization, because outside of the filesystem, there's no cross-app/desktop standard for photo organization the way there is with music files for example, where correctly-tagged music can be displayed in any sane music library app. This is quite an unpleasant thing to realize after you switch photo apps--or even worse, switch whole platforms--and the careful organization you did in the old app is completely lost in the new one. So I think if we did implement this, we'd want the underlying data structure to remain portable such that other apps can make use of it in a sane way. So it might be best if this was implemented in such a way that changes made for this are actually reflected in the filesystem. e.g. a photo appearing in multiple places could be symlinked or hardlinked from its original location to the other one, and creating a new album just created a new folder on disk. |