Pull to refresh
8
0
Дмитрий Соколов @Assador

Web-разработчик

Send message

Вообще ничего не крутил. По дефолту.

Ну да. Построит. Такого построит! Вот, что он мне выдал чуть позже ))

Задал тут ему вопрос. Такой потрясающей фигни я ещё не видел ))

Эх. Простите за крик души, но надо разрабов при приёме на работу заставлять на собеседовании в течение часа повторять скороговорку: «Фреймворк на фрейморке работал в фреймворке, но я под фреймворками фреймворкать не буду»! Скоро для console.log с десяток конкурирующих фреймворков напишут.

Нет, всё хорошо, но про дегустацию — огонь ) Лучше вы там у себя на Земле сами. Мало ли чо… )) Понос в космосе, должно быть, незабываем…

Чтобы можно было съе^Wулететь куда-нибудь после ядерной войны. Годно!

Чем бы дитя не тешилось, лишь бы не руками…

Ну, значит плохо искал. Да и тем более. Пусть растут все цветы. Даже если это кактусы )

Может быть… Хотя, не совсем понимаю, чем плоха обычная таблица в базе, без привязки к другим классам определённых баз. Так, по-крайней мере, очень легко расширять, добавляя новые поля, привязки и т. п. А так, чтобы присобачить к каждому месту, например, фотоальбом, или ту же принадлежность определённой папке в дереве, насколько я понимаю, придётся городить огороды. Хотя, чёрт его знает. По правде говоря, впервые вижу этот Point Class.

Точнее, в приведённом вами примере не меняешь «людей» на «друзей», а добавляешь тэг «друзья». «люди»-то остаются, раз родительский тэг к друзьям.
Нет, но это уже вопросы к Geeqie. Хотя, и не к ней.

Дерево — в XML-файле. Сами тэги — в тысячах файлов по всему миру могут быть :) Как можно это представить? Хранить в базе пути ко всем файлам?

А вот тут как раз и вступает в дело моя прога. Переместил в дереве Васю в «друзья» из «людей» — запускаешь мою прогу, скармливаешь ей корневой путь ко всем фоткам и меняешь во всех них пакетно «людей» на «друзей». Заодно можно добавить тэг «собутыльник».
А ваша программа очень заинтересовала. Жду версию для Linux. Очень хочется пощупать!

Вообще, я давно задумывался о более глобальном тэггировании. Моя прога-то, хоть и ИМХО очень полезна, но только для тех файлов, что поддерживают XMP / IPTC. Плюс, да — нет иерархии, а просто plain-список тэгов непосредственно в файлах. А иерархия в XML-дереве. C другой стороны, так ли она нужна именно в файлах? Как я уже написал в соседнем своём комментарии, при непосредственно тэггировании при добавлении потомка так же добавляется и родитель. Так что можно искать как по всем “people”, так и просто конкретно по Васе, который тоже “people” (ну, я надеюсь :)
Самим первоначальным тэггированием я занимаюсь как раз в Geeqie. Когда для каждой конкретной фотографии смотрю, какие нужны тэги. И там — да. Если добавляешь потомка, то добавляется и родитель. Всё верно. И поиск по “what” должен выдать фотки с “people”, поскольку в фотках есть и тот, и другой тэги (ну, конкретно, в случае с “what” — нет, это просто контейнер; а вот, например, “people → “Вася” — да, и тот, и другой).

Но у моей программы функция другая. Не обрабатывать каждую конкретную фотографию, а производить пакетные поиск и при необходимости замену, а также клепать сборники. Это «пакетный» функционал, чего не умеет та же Geeqie. Они у меня просто превосходно дополняют друг друга. Но и без Geeqie прога самоценна. Если знаешь примерный набор тэгов в некотором наборе картинок, можно так же искать, менять и т.д.

Насчёт хранения иерархических тэгов — не знаю. По крайней мере, что касается тэгов в метаданных стандартов XMP и IPTC, там этого нет. Либо пилить свой велосипед с дополнительными файлом(-ами) или базой etc, либо погуглить; может, есть ещё какие-то стандартизированные возможности для этого.
Дерево тэгов не имеет прямого отношения к тэгам картинок. Этого дерева вообще может не быть, я его сделал просто для удобства.

Предполагается, что у каждой картинки есть какой-то свой список тэгов. Каждой картинке можно назначить какие угодно и сколько угодно произвольных тэгов. Они хранятся в самих картинках.

Но поскольку я проставлял картинкам свои вполне определённые тэги, я список всех когда-либо вообще проставленных мной той или иной картинке тэгов для своего удобства ещё и сформировал в дерево. Что может сделать каждый. Дерево хранится в XML-файле. Там его можно править. Ну, либо, в Geeqie для наглядности.

Сами же конкретные тэги картинок хранятся в самих картинках. Просто каждая картинка в данном конкретном случае содержит определённое количество определённых тэгов из этого дерева.
Сами тэги хранятся непосредственно в метаданных картинок, в самих файлах. Это стандарты. См. Википедию: XMP, IPTC.

Дерево английских тэгов на скриншотах — моё личное, существующее в реальности. Это мои, мной придуманные тэги, которые я присваивал картинкам (записывая их в этих метаданных в файлах). Просто как-то так повелось, что они латиницей, а создавать специально для скриншотов отдельное дерево тэгов как-то долго и лениво. А кириллические тэги в полях — просто для примера, для поста. В нормальной рабочей ситуации, естественно, в поля добавляются реальные тэги из этого дерева тэгов. Иначе просто ничего не найдётся — в файлах-то, предположительно, тэги из дерева…
Вообще, да. Так логичнее. Поправил сам скрипт, закоммитил, поменял описания в статье и на сайте. Спасибо.
И, кстати, в вашем примере без ключа -p скрипт пишет в лог также суммирующую информацию, так что пайпить уже не комильфо. Вот, кстати, вопрос, надо ли писать в лог эту инфу…
Именно. После редактирования (при необходимости) log.txt, просто пишем

$ cat 'log.txt' | xargs rm

Ну или, если не собираемся просматривать и редактировать список файлов, можно и в одну строку:

$ ds-findorphaned -prR -d "~/maybe_orphaned_images" -f ".*\.jpg$" -D "~/search_here, ~/and_here" -F ".*\.php$" | xargs rm

Но я бы не стал. Как я уже писал, неупоминаемость файлов — лишь один из признаков ненужности. Так можно удалить что-нибудь нужное.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity