LINUX.ORG.RU
ФорумTalks

Концепция Модерновой Системы Управления Личными Файлами (не совсем ФМ)

 ,


1

1

Как я представляю себе современный файловый менеджер (для управления личными файлами). Это, на самом деле, больше про пользовательский интерфейс и практику использования, чем про функциональность.

Вводится понятие «проекта». Проект — это папка, которая является элементарной индексируемой единицей. Поиск производится по проектам. Как правило, проект состоит из одного или двух уровней, то есть в нем либо нет папок, либо есть папки, в которых уже не будет папок. Все личные файлы лежат в проектах. Проекты по папкам не раскидываются.

При открытии файлового менеджера открывается список проектов, а фокус находится в строке поиска. Нажимать Ввод для поиска не нужно, он будет выполняться с набором текста. Результаты поиска сортируются по-умному: если я вводу «фо», то впереди будет проект «Форд», а не «Отредактированные фотографии». Поскольку проектов едва ли будет больше тысячи-другой, а у большинства пользователей, в том числе и у меня, не больше сотни-другой, поиск выполняется очень быстро.

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

В принципе, в своей основе это все. Плюс к этому можно навесить дополнительной функциональности, такой как: теги для проектов (для проектов!); поля «дата (время) открытия проекта» и «дата (время) закрытия проекта», подразумевающие два возможных статуса проекта (открыт и закрыт, можно добавить еще статус «заморожен») с возможностью, соответственно, поиска, выбора и сортировки по этим временам и по статусу; закрепление проектов вверху списка; возможность размещения проектов на разных дисках или в разных папках, при том, что список проектов в программе — общий; умное использование этих дисков, то есть рациональное распределение проектов между ними; анализатор использования дискового пространства (дисковое пространство, которое занимает проект, подсчитывается заранее и обновляется при изменении проекта); классический файловый менеджер для работы со служебными (системными) файлами; анализ частоты обращения к проектам; стандартные ФМовские фичи (работа с архивами, массовое переименование, расширенный поиск, перемещение, линкование, копирование, ftp, smb...)

Не подскажете ничего в этом роде? (Про гном-шелл / юнити / etc знаю. Они неадекватно тяжелые).



Последнее исправление: nightingale (всего исправлений: 2)

Чувствую, называться сабж будет Telepath...

nightingale
() автор топика

Ты говоришь, что в проектах папок не будет. Или будет, но только один уровень. И как будут структурировать в них данные, т.е. файлы, если одного уровня папок им недостаточно?

При открытии файлового менеджера открывается список проектов, а фокус находится в строке поиска. Нажимать Ввод для поиска не нужно, он будет выполняться с набором текста.

Это слишком уж мелочи, чтобы учитывать их при контурном описании. И кстати, инкрементарный поиск (без нажатия кнопки Ввод) - идея очень спорная с точки зрения UX, а конкретнее - с точки зрения человеческих рефлексов. К примеру, посмотри на опыт Гугла, имеющего признавать свои ошибки: некоторое время там был инкрементарный поиск, но потом его снова убрали.

Deleted
()
Ответ на: комментарий от Deleted

Ты говоришь, что в проектах папок не будет. Или будет, но только один уровень. И как будут структурировать в них данные, т.е. файлы, если одного уровня папок им недостаточно?

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

nightingale
() автор топика
Ответ на: комментарий от Deleted

Это слишком уж мелочи, чтобы учитывать их при контурном описании. И кстати, инкрементарный поиск (без нажатия кнопки Ввод) - идея очень спорная с точки зрения UX, а конкретнее - с точки зрения человеческих рефлексов. К примеру, посмотри на опыт Гугла, имеющего признавать свои ошибки: некоторое время там был инкрементарный поиск, но потом его снова убрали.

Дело в том, что поиск в моей концепции — это не тот поиск, который прям поиск-поиск. Вот, представь, тебе нужны какая-то папка с файлами, ты открываешь традиционный ФМ, вспоминаешь, где, она лежит (в какой папке, возможно, на каком диске...), потом идешь по этому пути. Я бы хотел все это упростить до набора двух-трех букв. А поиск по базе из тысячи-другой записей — он же мгновенный сейчас.

nightingale
() автор топика
Ответ на: комментарий от nightingale

По идее, то, что ты описал, можно попробовать навилосипедить.

На рабочем столе создаешь папку Projects. В ней все проекты. В корневую папку каждого проекта скидываешь файл project.description, в который вручную записываешь информацию для последующего индексируемого поиска.

Устанавливаешь утилиту, умеющую в полнотекстовой поиск. Настраиваешь её, чтобы по деволфту искала только по файлам «project.description» в папке «Projects».

Deleted
()
Ответ на: комментарий от Deleted

Дело в том, что поиск в моей концепции — это не тот поиск, который прям поиск-поиск. Вот, представь, тебе нужны какая-то папка с файлами, ты открываешь традиционный ФМ, вспоминаешь, где, она лежит (в какой папке, возможно, на каком диске...), потом идешь по этому пути.

А из поисковых утилит попробуй Google Desktop. Я им давно не пользовался, но тогда понравилось. Кажется, работал инкрементарно или очень бликзо к тому.

Deleted
()
Ответ на: комментарий от Deleted

Пытаюсь навелосипедить. Только вместо project.description лучше использовать название директории (вообще, всякие левые файлы в директории — дурной тон, я считаю; Thumbs.db какой-то; системные данные должны быть среди системных файлов, так и база должна быть в системе, отдельно от данных). Утилиту для поиска не посоветуешь?

nightingale
() автор топика
Ответ на: комментарий от Deleted

А из поисковых утилит попробуй Google Desktop.

Где бы его найти... Разработка прекращена, у гугла не скачать. На AUR нет... (ArchLinux).

nightingale
() автор топика
Ответ на: комментарий от nightingale

Я им пользовался лет 5 назад, поэтому неудивительно что ошибочка вышла. Но может, тебе здесь другую поисковую утилиту посоветуют. В них вроде недостатка нет.

Deleted
()
Ответ на: комментарий от stevejobs

Так они же только про разработку кода, не? Неужели могут заменять ФМ?

nightingale
() автор топика

О найс, весна близко!

Ygor ★★★★★
()

То есть, если ты назвал файл как-нибудь по-дурацки или получил его из чужих рук, то ничего ты и не найдешь.

abraziv_whiskey ★★★★★
()
Ответ на: комментарий от abraziv_whiskey

Почему? Все файлы по проектам, в проекте файлов не очень много. Проекты появляются, ну, не сто раз на дню, и уж их-то можно нормально называть. В традиционном подходе ты вместо этого выстраиваешь иерархию директорий, что сложнее с обоих точек зрения: сложнее делать и администрировать, сложнее использовать.

nightingale
() автор топика
Ответ на: комментарий от nightingale

То, что ты ищешь в винде называется Библиотеки.
Гугли, может есть готовые решения для реализации такого же функционала в лине, по аналогии.

int64
()
Ответ на: комментарий от int64

Ок, гуглю. Надеюсь, это не будет выглядить настолько омерзительно, как новомодные (после икспи) интерфейсы виндоус :)

nightingale
() автор топика
Ответ на: комментарий от nightingale

Это никак не выглядит по особенному. Это просто нативная мета-надстройка над дефолтным файловым менеджером ОС. Библиотеки - это такие коллекции чего-либо (папок\файлов), отображенные только в асбтрактность (в бд), а не физически представлены на диске, поиск при этом идет именно по библиотекам, как ты хочешь. При этом разные файлы и папки могут одновременно быть в разных библиотеках, без всяких сим\хард-линков.

В интефрейсе это представленно просто отедльным разделом в файловом-менеджере - Библиотеки, заходя в который ты видишь список всех библиотек и можешь искать по ним. Сами библиотеки выглядят как и другие сущности ФМ - иконки с подписями.

int64
()

Людям не то что теги расставлять лень, файлы по директориям раскидывать осмысленно. Будет у большинства проект «Downloads», проект «Мои фотки» и проект «Разное».

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Будет у большинства проект «Downloads», проект «Мои фотки» и проект «Разное».

Ну, и нормально. Потом они станут Downloads 2017, Downloads 2018... Просто, лично у меня (и, думаю, я не один такой) кроме Downloads, фоток и Разного есть проекты по работе, папки по учебе, личные проектики, словом, много чего. За много лет получились сотни директорий, раскиданных по разным дискам и еще зачем-то (экой херней я занимался) лежащие в других директориях, которые лежат в других директориях... Это из-за отсутствия тегов, хотя и без тегов можно обойтись (как опция пускай будут).

nightingale
() автор топика
Ответ на: комментарий от int64

Да это я так, о виндоуском проводнике в целом, ругаюсь... Не люблю модерновую винду...

nightingale
() автор топика

У меня есть OmniFocus, который делает вот это все:

теги для проектов (для проектов!); поля «дата (время) открытия проекта» и «дата (время) закрытия проекта», подразумевающие два возможных статуса проекта (открыт и закрыт, можно добавить еще статус «заморожен») с возможностью, соответственно, поиска, выбора и сортировки по этим временам и по статусу; закрепление проектов вверху списка;

У меня есть скрипт для OmniFocus, который создает для проектов папки. И у меня есть LaunchBar, в котором поиск настроен по этим самым папкам. Вопрос: кому нужен такой велосипед, если 2 софтины и 20 строчек скрипта на AppleScript хватило чтобы покрыть 90% запрошенного функционала? Вот такой вот UNIX™-Way.

ptarh ★★★★★
()
Ответ на: комментарий от eR

Чем метафора проще, тем лучше. Поэтому "Folder" рулит. А логические диски можно называть "Binder" (но лучше не надо).

Ring binders are large folders that contain file folders or hole punched papers.

Deleted
()

Проект — это папка

мамка

Deleted
()

уже запутался. обоснование введению термина «проект» в студию.

system-root ★★★★★
()
Ответ на: комментарий от Deleted

По дефолту делает умный не рекурсивный поиск в заданных директориях (по дефолту это директории с запускаемыми файлами /usr/bin, /usr/local/bin и т. д.) с набором каждого символа и запускает набранный или выбранный файл. Есть всякие плагины для него и скрипты, его использующие, позволяющие делать что угодно...

nightingale
() автор топика

Семантический десктоп изобрести пытаются лет 15 уже.

DNA_Seq ★★☆☆☆
()

С столь идиотскими ограничениями на структуру хранения данных тебе надо обращаться на форумы эппла - там подобную хрень обажают.

najlus ★★★★★
()

Проекты по папкам не раскидываются.

ну и? перенёс все файлы из глубоко вложенных директорий в несколько директорий и назвал это проектом

При открытии файлового менеджера открывается список проектов

любой файловый менеджер

а фокус находится в строке поиска. Нажимать Ввод для поиска не нужно, он будет выполняться с набором текста. Результаты поиска сортируются по-умному: если я вводу «фо», то впереди будет проект «Форд», а не «Отредактированные фотографии».

примерно строк 15 чтобы допилить любой опенсорсный файловый менеджер: проще сделать самому, чем искать подходящий

Поскольку проектов едва ли будет больше тысячи-другой, а у большинства пользователей, в том числе и у меня

фейл этой концепции в том, что пользователю всё равно придётся вручную рассортировывать фоточек с камеры и котиков из интернетов по проектам а это муторно, когда они исчисляются десятками тысяч

next_time ★★★★★
()

Можно я вставлю 2 копейки?

На самом деле файловая система НЕ НУЖНО.

Это наследие из 80х. Из времён ещё tr-dos. В реальности у тебя есть файлы разного типа, которые должны собираться в коллекции. Оные могут быть иерархическими, там могут быть перекрестные ссылки на другие коллекции. Например фотка «я и жена в Мадриде» может ссылаться ещё и на видео.

ckotinko ☆☆☆
()

Далее, тебе нужен не файловый менеджер, а менеджер файлов. Файлов, которые имеют тэги для поиска, очередей для сортировки(например «новые фото где я ещё не поставил тегов). Это можно сделать через базу данных плюс набор каталогов.

ckotinko ☆☆☆
()

Далее, надо подумать об интеграции с qt и gtk. Это dbus ибо тебе придется держать демона для обработки запросов, патчи для диалога и т.д.

ckotinko ☆☆☆
()

Комментарии не читал.

  • сортировать нужно по дате последнего изменения или обращения(длинный архив не должен мешать).
  • ограничение на папки не нужно, роботы умеют обрабатывать длинные пути/имена, для поиска можно считать «/» эквивалентом " " - разделителем слов.
  • большая часть «доп возможностей», кажется, переводит всё в состояние блоатвари.
  • тяжесть понятие относительное, тяжёлый но постоянно запущенный и уже существующий процесс субъективно(в смысле UI) лучше лёгкого но недописанного(man emacs).

А вообще, я бы посмотрел на пользовательский шел в стиле DF, такой удобной работы с большой кучей всякой всячины больше не встречалось.

DonkeyHot ★★★★★
()
Ответ на: комментарий от user42

В этом случае, как раз, папки - в таких интерфейсах они не используются для организации поиска данных, можно с таким же успехом держать в одной куче. Каталоги(по твоему «директории» - что на целый слог длиннее, т.ч. не нужно) в этом случае - это те БД, которые должен будет subj использовать для ускорения себя.

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от nightingale

системные данные должны быть среди системных файлов, так и база должна быть в системе, отдельно от данных

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

Tark ★★
()
Последнее исправление: Tark (всего исправлений: 1)
Ответ на: комментарий от next_time

Возможно, каждому свое, но для меня сохранить фотки с вылазки как проект «Мухосранск Февраль 2018» - нечто само-собой разумеющееся. Более того, я слабо предстааляю себе, а как иначе-то.

nightingale
() автор топика
Ответ на: комментарий от Tark

Вот как-раз этого и хочется избежать. Винда понаделала тумба-дб и десктопа-ини, а теперь я с линукса смотрю, эти файлы видны, мешаются и бесят. В то же время указать ссылку на один общий файл базы данных файлового менеджера, если вдруг на другой машине или в другой системе он тот же (необычайная редкость) не стоит почти ничего.

nightingale
() автор топика
Ответ на: комментарий от nightingale

Про права доступа не забыл? Ну и частичный доступ например. А еще файлы надо вместе с БД копировать, так как она может измениться во время копирования.

Tark ★★
()
Последнее исправление: Tark (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.