[К wiki] Графический поиск в XFce Desktop
На полноценную статью не тянет и не может тянуть, и всяко за неимением действующей русскоязычной wiki стоит отметить, чтобы не искать потом.
Ибо тов. гугль полностью оправдывает свою суть (правильное описание можно найти разве что на основании уже известного ответа, но не вопроса).
Задачу можно решить двумя способами:
dev-util/catfish (по состоянию на 24.04.2013 дерево предлагает версии ~0.3.2 ~0.3.2-r1 ~0.4.0.2)
gnome-extra/gnome-search-tool (по состоянию на 24.04.2013 в дереве версия ~3.6)
Очевидным образом оба решения локализуются в тестовой ветке.
Как минимум для пользователя стабильной ветки (amd64) оба отсутствуют.
Размаскировать (добавить KEYWORD ~arch) и установить (лично я склонен предпочесть dev-util/catfish).
Остаётся настроить обработчик в файловом менеджере (предполагая родной для DE xfce-base/thunar (в наличии 1.6.2)):
Правка -> Особые действия -> Добавить ('+').
Вкладка "Основное":
* Имя: Поиск файлов
* Описание: [здесь у меня фантазии не хватает]
* Command: catfish --fileman=thunar --path=%f
Вкладка "Условия появления"
* Шаблон имени файла: *
* Появляться, если выделение содержит: проставить checkbox на каталог.
И всё. При выделении каталога в меню, вызываемом по правой кнопке мыши появится пункт "Поиск файлов".
Картинку не показываю, ибо на форуме ей не место.
http://docs.xfce.org/xfce/thunar/custom-actions
ЗЫ: Для gnome-extra/gnome-search-tool без проверки и перевода:
Name: Search…
Command: gnome-search-tool –path=%f
File pattern: *
Appears if selection contains: Directories
Update: Товарищи обратили внимание на наличие пункта "Поиск" в стандартом окне открытия файла gtk-приложений (то самое стандартно-предустановленное решение). По моему опыту: разделять файлы с совпадающими (стандартными) базовыми именами оно не сильно поможет. Хотя пристрастно не изучал.
- Для комментирования войдите или зарегистрируйтесь
catfish я пробовал, склонился
catfish я пробовал, склонился к тому, что locate и find работают понятнее и быстрее. Кривоватая поделка со смутной логикой.
/
Косвенным указанием на это является то, что без подсказки я благополучно прошёл мимо этой задачки.
Но многим из адаптирующихся пользователей наличие графической... альтернативы... желательно.
:wq
--
Live free or die
«адаптирующимся»
«адаптирующимся» пользователям сия «альтернатива» будет стоить немалого труда по освоению. Ибо работает она как угодно, только не интуитивно-понятно. А местами так и вообще непонятно.
/
С этого момента прошу поподробнее:
Какую версию пробовал, с каким back-end'ом?
Ну и хотя бы один пример косяка для случая простого поиска по имени файла (или ты думаешь, что простой "применитель компутера" (как любит выражаться тов. Федорчук) зачитает
man findи задаст дополнительных условий по типу, размеру и прочая?).:wq
--
Live free or die
Давно было, нюансов не помню,
Давно было, нюансов не помню, но с locate что-то точно не срасталось. Ну и результаты получались не такие как ожидалось. По моему мнению — если гуй, призванный быть «альтернативой» консольным утилитам, требует мана — это говногуй и не_нужен.
/
Ай-яй-яй... А как хорошо всё начиналось...
Не, так годного флейма у нас не получится. :)
Ты критикуй сперва результаты использования стандартных утилит (
find).Касаемо же применимости использующих для ускорения поиска собственные индексные базы к поиску по пользовательским данным могу надиктовать список ограничений по условиям применимости.
Способ поддержания в актуальном состоянии базы
man-dbздесь достаточно информативен и показателен.:wq
--
Live free or die
а чего тут флеймить? если ты
а чего тут флеймить? если ты что-то ищешь, то скорее всего заранее знаешь, есть ли это, скажем, в базе locate или надо использовать find. а графическая утилита таки должна как-то сама работать, без долгих изучений, и работать правильно и предсказуемо. В целом — она должна упрощать а не усложнять выполнение задачи.
Стандартизация один из
Стандартизация один из способов упрощения. Каким образом использовать гуй в скрипте? Что делать при отсутствии гуя? Каким образом при помощи минимального количества элементов подстройки имитировать гибкость утилиты командной строки? Имхо линь это осознанный выбор тех, кто осознал неэффективность гуя в решении рутинных задач.
ЗЫ
Тому, кому нужен графический поиск вряд ли доберутся до данного поста. Тому, кому сей поиск мешает вряд ли по достоинству его оценят. Вывод - подобный функционал должен быть предустановлен и не требовать настройки, ибо в противном случае никогда не будет использован.
/
Вопрос: насколько часто востребована и практически в полной мере используется та самая "гибкость командной строки"?
Одно из возможных решений задачи.
Пусть даже оптимальное и правильное.
Но не единственное!
Последние (закономерные) тенденции в разработке альтернативной ОС обеспечат массу несознательных пользователей.
И к этому надо готовиться. Иначе нанесут нам вожделенной "НТ-прогрессивности", "только лучше и забесплатно" (на самом деле уже нанесли... больше чем можно нормально переварить). А потом подтянутся решающие насущнейшую проблему оттока источников прибыли корпорации...
Не соглашусь.
Даже в рамках этой в общем-то простой задачи имеем отсутствие простого (однозначного) решения (особенно если не забывать, что идентификация и выпиливание ненужного просит ресурсов не меньше, чем сборка своего конструктора как надо).
Более того: мимо слона-то я как раз благополучно прошёл мимо (спасибо товарищам, обратили внимание). В стандартом меню открытия файла (gtk-приложений) помимо "Недавних документов" присутствует и "Поиск".
Так что вопрос о сути поиска (какой, где, зачем и насколько нужен?) не так прост, как может показаться.
Промежуточный итог: прежде чем что-то встраивать в коробку, пользователя надо учить :) Заодно и самим хороший повод пересмотреть базу знаний (применительно к теме: какие задачи должны решаться в рамках десктопа, какие опциональны и чем их можно (рекомендуется) решать).
Вывод: даёшь!!! (wiki.gentoo.ru)
:wq
--
Live free or die
Подойдем с другой стороны. А
Подойдем с другой стороны. А именно — почему такое решение является неудачным? По одной простой причине — мы работаем с файлами в определенной среде — будь то тунар, проводник, 2х-панельник или терминал. И совершенно нелогично и неудобно, что получаемый сторонней утилитой поиска список файлов не подчиняется тем же соглашениям об интерфейсе, что и «обычный» список.
Ведь _найти_ файлы — это полдела, с ними что-то бывает нужно и сделать. И сделать это единственно логично теми же методами, что и непосредственно в используемой среде. То есть, тунару необходим встроенный поиск. (ему вообще много чего необходимо). А поскольку такового нет — нечего и время тратить на поделки, изначально спроектированные не для решения задачи, а для его имитации.
/
Сортировка --- отдельная песня.
Соблюдение договорённостей о сортировке должно решаться не на уровне прикладных приложений.
Обрати внимание: Thunar сортирует кириллицу иначе, чем стандартное окно открытия gtk-приложений.
Это бага. Доисследую --- отрапортуюсь. Не обижусь, если это сделает кто-то ещё.
Строиться полагаю правильным от терминала :)
Двухпанельники оставь родной среде.
Читай рассуждения тов. wi о гибкости.
Без списка что [именно] делать с указанием весовых коэффициентов востребованности, приводимое замечание немногого стоит.
* задумался акцией по троллингу пользователей альтернативной ОС на родных ресурсах наглядными примерами убогости порождений особенности реализации оставленной милостью билли командной строки
Нам же дух "НТ-прогрессивности" на фиг не нужен!!!
Для тех задач, где может иметь смысл файломенагер, Thunar очень хорош (приведи лучшее решение).
Там же, где ему "много чего не хватает" горождение костылей для решения задачи с завязкой на файломенагер оставим фанатам сего порождения интуитивно-понятного интерфейса.
:wq
--
Live free or die
>горождение костылей для
>горождение костылей для решения задачи с завязкой на файломенагер оставим фанатам сего порождения
это такая иезуитская самокритика, что ли? ;)
>Сортировка… что [именно] делать…
при чем тут сортировка? я говорю о том, что получившийся в рез-те «поиска» список файлов должен являться, быть, выглядеть и крякать _так_же_, как и любой другой прочий список файлов — в используемой нами среде. А не представлять для этого зачем-то _свой_ уникальный интерфейс и функционал. Сортировка — это всего лишь один малый аспект.
>Двухпанельники оставь родной среде.
а тунара, как очевидного родственника проводника, значит признаем родным? А ну не холиварить тут! ;)
.
Иезуитам ещё поучиться у тебя искусству чтения :)
Я вот видел каково работает решение, о котором ты говоришь.
Не стал бы называеть его удачным.
Снова иезуитские практики?
С генезисом проводника совсем не знаком?
Смотри на файловый менеджер Common Desktop Environment.
И вообще, с таким подходом выпилил бы ты уже thunar, и проследовал на три буквы (в смысле на rox, хотя оно вроде бы уже домутировало до DE...)
:wq
--
Live free or die
>Иезуитам ещё поучиться у
>Иезуитам ещё поучиться у тебя искусству чтения :)
что ж… приходи учиться :D
>Я вот видел каково работает решение, о котором ты говоришь. Не стал бы называеть его удачным.
Ну и чего же ты видел? тунар — первый FM, из тех, что мне попадались, который _не умеет_ искать файлы, что трудноотделимо от возможности представления этого массива аналогичным простому списку директории образом. Мне так вообще казалось, что этот функционал — практически непременная часть FM. В конце концов, эта абстракция несложным образом достижима даже в терминале — неужели оппонент не пользовался xargs к примеру?
>С генезисом проводника совсем не знаком?
так или иначе очень многие интерфейсные решения «слизываются» откуда ни попадя, не суть это важно, не буду я срач на эту тему разводить. Вообще, для многих тот же MC вполне родной, и таки (хоть и не лучший он из 2х-панельников и концептуально изрядно испорчен как раз линуксо-ортодоксами), тунар по функционалу и информативности с ним и рядом не валялся.
>выпилил бы ты уже thunar
выражаясь твоим стилем — надо исправлять, а не отбрасывать в сторону. Тунар совсем не плох концептуально, ему просто многого не хватает, к тому же он достаточно интегрирован в XFCE. И недостающий функционал всяко не костылищами надо заменять, а доводить [до] разработчиков.
.
В тебе говорит импринтинг неназываемого двухпанельника, и ты забываешь о совокупности факторов, породивших его.
mc по факту не пользовался, так что можно обойтись без упрощений в виде сравнения с некоторым образцом, объявляемым эталоном.
Выражаясь моим штилем, прежде чем генерить тонны кода полезно задаться вопросами о том, для решения каких задач (ну окромя архинесущной в виде ИБД) потребен файломенагер, что для этого ему нужно и о значности сходимости решения задачи типа "файломенагер" (в данном конкретном случае вопрос о возможности гармоничной интеграции в Thunar подсистемы, удовлетворяющей твоим требованиям к поиску).
Каковое обсуждение, думается мне, заслуживает отдельной темы.
ЗЫ: Также стоит отметить, что некоторые проблемы, _наблюдаемые_ в Thunar'е являются результатом ляпов не только (вплоть до "не столько") его разработчиков.
:wq
--
Live free or die
dev-util/catfish
dev-util/catfish
Available versions: ~0.3.2 ~0.3.2-r1 ~0.4.0.2
Homepage: http://launchpad.net/catfish-search http://twotoasts.de/index.php/catfish/
Description: A frontend for find, (s)locate, doodle, tracker, beagle, strigi and pinot
Подскажите, что за doodle и pinot? А то на его хомяке, нет ни списка возможностей, ни списка поддерживаемых бэкендов, нашел на лончпаде ридми - и тот куцый. тупикал опенсорц.
:)
http://blogs.gentoo.org/night
http://blogs.gentoo.org/nightmorph/2010/09/02/searching-the-desktop-with-pinot-and-catfish/
Насчет doodle - хз.
Нейтральность - высшее достижение сознания!