Фильтры

Разработка Far.
Post Reply
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Фильтры

Post by DrKnS »

У меня есть желание расширить и углубить сабж.

Примерный план:
  • "Группы масок" убираются. Вместо этого к фильтрам можно обращаться по <имени>, как сейчас к группам.
  • Из раскраски убирается фильтрующая часть, остается только настройка цвета и выбор сопоставленного фильтра из глобального списка (примерно аналогичного тому, что сейчас по Ctrl+I, но без автофильтров). Примеры:
  • То же самое для групп сортировки.
  • Возможно то же самое для ассоциаций. Примеры:
  • Существующие группы раскраски, сортировки (, ассоциации) конвертируются в фильтры автоматически.
Иными словами, фильтр приобретает значение "группа файлов по какому-то критерию" и становится глобальной сущностью, к которой можно прицепить раскраску, сортировку, ассоциации, в перспективе что-то еще.

Особенно интересует мнение тех, у кого всего этого много.
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Фильтры

Post by HaRT »

DrKnS wrote: Wed 04 Nov, 2020 19:21 Особенно интересует мнение тех, у кого всего этого много.
Например, тех, кто пользуется Атрибуцией (лично я как-то от неё отошёл при переходе на Фар 3). В целом идею поддерживаю. У меня и так почти вся раскраска построена .

Только хочется обсудить, чем заменить возможность составлять группу масок из групп масок (т.е. выстраивать их в иерархию). Например, у меня есть группы media_aud, media_pic, media_vid, состоящие из огромного числа расширений, и группа multimedia, определённая как <media_aud>, <media_pic>, <media_vid>. Очень не хотелось бы дублировать те длиннющие списки (да и, помнится, в какой-то момент я потому и разделил их, что упёрся в ограничение на длину поля).

Кроме того, у меня есть предложения по изменению проекта UI. Как лучше, сейчас или когда уже появится рабочий прототип?

Кстати, предлагаемые изменения тянут на увеличение хотя бы минорного номера версии.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Фильтры

Post by DrKnS »

HaRT wrote: Wed 04 Nov, 2020 22:28 чем заменить возможность составлять группу масок из групп масок (т.е. выстраивать их в иерархию)
А она должна остаться. "К фильтрам можно обращаться по <имени>, как сейчас к группам" подразумевает то, что в любое место, где ожидается маска (в т.ч. в другой фильтр), можно будет ввести <имя фильтра>, из этого фильтра будет взята маска (если есть) и использована точно так же, как группа масок сейчас. Т.е. можно будет создать фильтр, ссылающийся на маски из других фильтров. Нужна ли возможность ссылаться на все остальное (т.е. иметь полноценную иерархию фильтров)? Я пока не уверен.
упёрся в ограничение на длину поля
Вроде бы сейчас длина поля ограничена только размером адресного пространства?
Кроме того, у меня есть предложения по изменению проекта UI. Как лучше, сейчас или когда уже появится рабочий прототип?
Лучше сейчас.
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Фильтры

Post by HaRT »

DrKnS wrote: Wed 04 Nov, 2020 19:21
// Кнопка [ Filter ] открывает меню фильтров. Выбранный фильтр MyFilter используется в этой группе раскраски ╔══════════════════════════ Files highlighting ══════════════════════════╗ ║ [ Filter ] MyFilter ↓║
Тут по сути реализуется стандартный паттерн Text input with Chooser button (только поле ввода с историей, но сути это не меняет). Поэтому предлагаю применить более стандартное расположение: (метка — чтобы придать горячую клавишу и полю ввода).
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Фильтры

Post by HaRT »

DrKnS wrote: Wed 04 Nov, 2020 23:18 можно будет ввести <имя фильтра>, из этого фильтра будет взята маска
Может, стоит уже сейчас ввести такой синтаксис, в котором будет явно указываться, что берётся именно маска (например, <My Filter Name|mask>)? Так и при чтении будет понятнее, и останется ясная возможность использовать («если ваще») какую-то другую часть фильтра в будущем.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Фильтры

Post by DrKnS »

HaRT wrote: Wed 04 Nov, 2020 23:41 Тут по сути реализуется стандартный паттерн Text input with Chooser button (только поле ввода с историей, но сути это не меняет)
Не совсем - поля ввода там нет, просто static text (т.к. варианты выбора фиксированы), из этих же соображений и кнопка слева. Но вообще это мелочи, я думал у вас там что-то кардинальное :)
Может, стоит уже сейчас ввести такой синтаксис, в котором будет явно указываться, что берётся именно маска
Explicit is better than implicit, да, но:
  • "в будущем" - это так, размышления, на этом все может и остановиться. Оно вам надо, дописывать |mask везде ради пуризма?
  • то, что будет использована только маска, как бы очевидно из контекста использования - ввод в поле "A file mask or several file masks". Если будет возможность комбинировать фильтры целиком, то для этого будет отдельный UI.
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Фильтры

Post by IgorZ »

DrKnS wrote: Wed 04 Nov, 2020 23:18 А она должна остаться. "К фильтрам можно обращаться по <имени>, как сейчас к группам" подразумевает то, что в любое место, где ожидается маска (в т.ч. в другой фильтр), можно будет ввести <имя фильтра>, из этого фильтра будет взята маска (если есть) и использована точно так же, как группа масок сейчас. Т.е. можно будет создать фильтр, ссылающийся на маски из других фильтров. Нужна ли возможность ссылаться на все остальное (т.е. иметь полноценную иерархию фильтров)? Я пока не уверен.
Хотелось бы уточнить. Сечас, для примера, у меня есть группа масок <Docs> (всевозможные документы). В раскраске я использую её два раза: для RO и RW файлов. В новом варианте это будут три фильтра: один - все <Docs> чисто по маске, второй и третий - <DocsRO> и <DocsRW>, ссылающиеся на первый и добавляющие от себя выбор по атрибуту. Если мне понадобится фильтр, условно, <LastWeekDocsRO> с выборкой документов только для чтения с датой за последнюю неделю, он будет ссылаться на <DocsRO>, добавляя выбор по дате, или же в него тоже придётся добавлять выбор по атрибуту? Как я понимаю, сейчас предлагается второй вариант?
Принципиальной разницы по сложности реализации между вариантами нет - в обоих случаях придётся разбирать цепочку (или дерево) рекурсивно до нахождения фильтра(ов), который(е) ни на кого не ссылае(ю)тся. Но первый вариант гибче, хоть и требует на обратном ходе не только проверять маски файлов на предмет добавления новых на очередном шагу, но и делать то же самое для любых условий фильтрования.
Возникает, правда, сложность, что делать, если очередной фильтр ссылается на два с противоположными условиями, например <ProgsRW> (исходные коды программ) и <DocsRO>. Но тут можно условиться, что у фильтров одного уровня ссылки условия логически складываются (маски файлов же складываются, а не перемножаются), и, если два условия не совпадают, просто отбрасывать оба. С датой и временем (и размером), где всё может быть сложнее, поступать так же - если фильтры не идентичны, выкидывать оба, то есть, фильтрация по времени (или размеру) вообще отменяется. А для фильтров разного уровня всё однозначно: одинаковые поля вызывающего (не совсем корректная терминология, но пусть будет) фильтра однозначно замещают поля вызываемого.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Фильтры

Post by DrKnS »

IgorZ wrote: Fri 06 Nov, 2020 07:47 Сечас, для примера, у меня есть группа масок <Docs> (всевозможные документы). В раскраске я использую её два раза: для RO и RW файлов. В новом варианте это будут три фильтра: один - все <Docs> чисто по маске, второй и третий - <DocsRO> и <DocsRW>, ссылающиеся на первый и добавляющие от себя выбор по атрибуту.
Да, все так: было 3 сущности и стало 3 сущности, но теперь все 3 можно использовать еще и панелях, например.
Если мне понадобится фильтр, условно, <LastWeekDocsRO> с выборкой документов только для чтения с датой за последнюю неделю, он будет ссылаться на <DocsRO>, добавляя выбор по дате, или же в него тоже придётся добавлять выбор по атрибуту? Как я понимаю, сейчас предлагается второй вариант?
Если под "ссылаться" вы понимаете "напишу <DocsRO> в поле маски" то да, второй вариант.
Принципиальной разницы по сложности реализации между вариантами нет - в обоих случаях придётся разбирать цепочку (или дерево) рекурсивно до нахождения фильтра(ов), который(е) ни на кого не ссылае(ю)тся. Но первый вариант гибче, хоть и требует на обратном ходе не только проверять маски файлов на предмет добавления новых на очередном шагу, но и делать то же самое для любых условий фильтрования.
Первый вариант, несомненно, гибче, но иерархия фильтров - это отдельный вопрос.
Для наглядности можно рассматривать маску как базовый класс, фильтр как производный, и считать, что при использовании фильтра в контексте маски происходит слайсинг.

Тут еще такой вопрос. Сейчас в far есть сущность "одиночный фильтр" (это, например, в раскраске) и "мультифильтр" (это, например, в панелях), состоящий из пользовательских одиночных фильтров и автофильтров (папки и расширения на панели), и позволяющий плюсами и минусами в меню построить что-то типа any_of(included) && none_of(excluded). Достаточно ли в раскраске (и т.п.) одиночного фильтра (выбрал один из списка) или лучше мультифильтр (выбрал несколько по +/-)?
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Фильтры

Post by HaRT »

DrKnS wrote: Fri 06 Nov, 2020 16:29 Достаточно ли в раскраске (и т.п.) одиночного фильтра (выбрал один из списка) или лучше мультифильтр (выбрал несколько по +/-)?
Учитывая, что любой аспект раскраски имеет флаг/состояние «transparent», не очень понятно, в каких практических ситуациях в раскраске может потребоваться мультифильтр.
Фар есть инструмент, а не нянька. © 2009 DrKnS
IgorZ
Posts: 790
Joined: Wed 13 Jul, 2011 03:32
Has thanked: 15 times
Been thanked: 93 times

Фильтры

Post by IgorZ »

Спасибо за уточнение.
DrKnS wrote: Fri 06 Nov, 2020 16:29 Тут еще такой вопрос. Сейчас в far есть сущность "одиночный фильтр" (это, например, в раскраске) и "мультифильтр" (это, например, в панелях), состоящий из пользовательских одиночных фильтров и автофильтров (папки и расширения на панели), и позволяющий плюсами и минусами в меню построить что-то типа any_of(included) && none_of(excluded). Достаточно ли в раскраске (и т.п.) одиночного фильтра (выбрал один из списка) или лучше мультифильтр (выбрал несколько по +/-)?
Посидел, подумал. Не смог придумать ситуацию, когда бы мне такое понадобилось. С другой стороны, внедрение Lua в Far мне когда-то тоже казалось излишеством. А теперь считаю его едва ли не сильнейшей фаровской стороной. Так что, наверное, если не жалко на это времени, пусть будет - глядишь, кому-то и пригодится. Может, даже и мне. Ну а нет - так нет.

P. S. Подумал ещё. Пожалуй, мультифильтры позволили бы лично мне слегка упростить и сделать нагляднее имеющиеся настройки раскраски. Не то, чтоб это было критично или, хотя бы, особо важно, но определённая красота в этом есть.
Last edited by IgorZ on Mon 09 Nov, 2020 11:14, edited 1 time in total.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Фильтры

Post by DrKnS »

Я почему спрашиваю - сейчас, например, нельзя создать OR фильтр по атрибутам: все помеченные атрибуты - это AND, все непомеченные - это NOT. В результате прямо изкоробки возникает идиотская ситуация "хотим раскрашивать скрытые и системные файлы одинаково, но фильтр так не умеет, поэтому приходится создавать 2 одинаковых раскраски".
User avatar
HaRT
Moderator
Posts: 10823
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

Фильтры

Post by HaRT »

DrKnS wrote: Thu 05 Nov, 2020 00:11 Но вообще это мелочи
Ещё одна мелочь: пожалуйста, в диалоге редактирования фильтра оставьте побольше ширины для меток Больше/Меньше (по размеру) и Раньше/Позже (по времени), чтобы можно было хотя бы себе в языковом файле прописать горячие клавиши. Ну а в идеале сразу их расставить, чтобы в каждое поле можно было попасть непосредственно.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
buniak_a_h
Posts: 4236
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 222 times
Been thanked: 643 times
Contact:

Фильтры

Post by buniak_a_h »

Я извиняюсь, если вопросы уже были в теме.
  1. Списки масок можно использовать в far.RecursiveSearch и far.ProcessName. Теперь вместо списков нужно будет указывать имя фильтра?
  2. Имя списка масок сейчас можно использовать в диалогах Select/UnSelect, а также в масках исключений (после |. Теперь там надо будет указывать имя фильтра?
  3. Правильно ли я понимаю, что теперь станут ненужными пункты [ Filter ] диалогов Select/InSelect и [ ] Use filter диалога Find File и т.п.?
Извините, пока не вижу преимуществ. Впрочем, пожуём-увидим.
Post Reply

Return to “Development”