nikostap Тоже с большим интересом прочитал всю ветку.
Верно то, что автор программы может хранить (технически) архивы, как нравится ему. Я свои рабочие задачи хранения документов программировал по советам Apache Proxy - ему оптимально в каждой папке не более порядка 256 записей (два очередных байта от uuid5), уровни вложенности меньше влияют на скорость доступа. Пользователей учу всё рабочее класть в “yyyy-MM/yyyy-MM-dd-nn человеко-читаемое что угодно” (моим программам важно именно “yyyy-MM/yyyy-MM-dd-nn” - до первого пробела, если есть), но у нас и требования хранить ВСЁ не менее 5 лет (фоток у людей побольше).
А вот для пользователей программы мне понравилась идея, что они сами смогут выбирать формат отображения, а при наличии навыков - прописывать в ini. Это, конечно, работа для автора - строить виртуальное дерево не 1в1 с физическим, но всего одна функция получения очередного виртуального элемента в перечислении. А для Экспорта из Tonfotos есть отдельная функция - чтобы не лезть под капот физического хранения.
Также мне понравилось, что здесь многие считают насущным даже в плоских структурах иметь предложенное в Выборка по фотоаппарату в EXIF, а Андрей всё ещё сомневается, кому это нужно.
Также-2: здесь проскочило, что сохранение (раскладка автором) по физическим датам теряет используемую многими предопределенную логическую структуру по событиям пользователя - Автоматический перенос названий папок в теги - так почему бы не записывать каждую новую раскладку в новый виртуальный альбом, который сохранит или исходное название папки пользователя, или (при отсутствии) технический термин как в Контактах на Android - “Импортировано 06.12”. Позже пользователь сам решит - удалить или переименовать название этого альбома, или удалить целиком этот импорт, или присвоить ему общие метки времени/места.
