Форкаю pcmanfm

и да, у файла есть свойства

зачем это знать виндузятнику?

В KDE все процессы выводятся в плазмоиде, общение с которым, между прочим, организуется через dbus и максимум можно добавить свой виджет к уведомлению. И всем побоку офигенно модульный ФМ, если он не умеет использовать средства KDE для отображения процесса копирования. Конечно, поведение плазмоида можно эмулировать, не забывая добавить кнопки «стоп» и «пауза» к окошку с прогрессбаром, просто потому что так принято в KDE.

В Unity процесс копирования отображается отдельным окошком, но при одновременном выполнении нескольких копирований окошко остаётся одно, в него добавляются новые прогрессбары. Есть кнопка стоп, нет кнопки пауза.

В каком-нибудь XFCE процесс копирования, скорее всего, тоже отдельным окошком, но не несколько процессов не складываются в одно окно.

Действительно, где тут look&feel. Давайте лучше обсудим, как написать очередной неюзабельный ФМ, нарушающий все принципы данного DE с криком «я тут король, а вы пешки!».

Почему не vifm?

Знаешь, как совместить грамотную обработку архивов с файловым менеджером

Не знаю :) Как в вендовом 7zip?

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

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

Суть в том, что разница как раз _принципиальная_.

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

Как в вендовом 7zip?

А как в вендовом 7zip? 7zip сможет открыть tar.gz так, чтобы ты не заметил разницы с обычным каталогом? Не сможет.

Это называется «написал много букв сам не знаю о чем». Ты хочешь смешать в кучу семантику и представление? Смешивай. Получишь очередной " неюзабельный ФМ, нарушающий все принципы данного DE", прямо как и хочешь.

Я же говорю _исключительно_ про семантику. И ничего не говорю про представление. Представление — другой уровень абстракции, на котором используются другие инструменты.

я б с удовольствием помог =)

Чем конкретно хочешь заниматься в рамках проекта?

ОП, расскажите, каким функционалом будет обладать конечный продукт? Какие цели ставятся?

Мне кажется, у людей в этом треде создается постепенно впечатление, что вы хотите несколько велосипедов сцепить чтоб получился тандем.

Плюсую этого оратора. geekless, я бы может и подключился, но я не понимаю, зачем это нужно, кто этим будет пользоваться (кроме тебя).

Чем это будет лучше thunar?

Лично я, например, использую файловый менеджер (thunar) для единственной цели: кликнуть по ярлыку «Downloads» и кликнуть на свежескаченный фильм, чтобы запустился видео-плеер, либо по-быстрому открыть документ какой-нибудь (doc,pdf,etc).

А вся остальная работа с файлами в консоли, так быстрее и удобнее.

А ещё, если надо удалить/переместить/скопировать кучу файлов, лежащих в одном каталоге, то из консоли по-быстрому: mc -> (ins + стрелочки) -> F6/F5/F8 -> F10 -> enter -> обратно в консоль.

Для моих задач твой чудо-форк будет в перспективе полезен?

да чем угодно. всё равно почти ничего не умею :D но учусь быстро =)

Желающие пользоваться навороченным pcmanfm не имеют навыков для помощи в разработке, а имеющие навыки не станут заморачиваться, т.к. предпочитают классические двухпанельники типа mc.

А ты не форкай - велосипедь с нуля, забудь про dbus,libhal,fam и прочую фигню, не старайся осчастливить мир и в 6-7 месяцев уложишься.

DE-фреймворк

тыц

libhal,fam

некромантэ отакуэ

Обращайся, когда надо будет тестировать (так сказать попробовать). Тоже стало интересно

ты сейчас именно pcmanfm и описал =)

ОП, расскажите, каким функционалом будет обладать конечный продукт? Какие цели ставятся?

Сейчас pcmanfm представляет собой следующее:

Имеются библиотеки libfm и libfm-gtk, которые реализуют всю ядерную функциональность файлового менеджера. Бинарник pcmanfm служит только мордой, которая собирает компоненты воедино и даёт пользователю взаимодействовать с ними.

Что я хочу сделать. Оставить в libfm только код, отвечающий за работу со свойствами и метаданными файлов (возможно, шире: любых виртуальных объектов, имеющих URI). То есть, задача libfm будет отвечать на вопросы типа «что ты знаешь про этот файл насчёт таких-то его свойств?». Это включает в себя как базовые свойства, такие как mtime, так и виртуальные метаданные, такие как «название песни» или «набор приложений, пригодных для открытия этого файла».

При этом у нас выделяются некоторые группы свойств, каждая из которых требует собственной логики. Например:

• Превьюшки.
• Контекстные меню файла.
• mp3- и exif- и т.п. тэги.

Сейчас обработка таких свойств достаточно негибка, много логики захардкожено непосредственно в libfm. Я хочу вынести столько логики в текстовые конфиги и во внешние утилиты, сколько это вообще возможно без существенной потери производительности.

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

Это означает, что даже такие пункты как «копировать» или «удалить» пользователь сможет заменить на собственные.

Это было первое.

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

Соотвественно, у нас появится возможность совершенствовать эти внешние приложения независимо от разработки ядра ФМ. Допустим, пользователю важна такая фича: возможность гибко настроить, какие именно файлы заменять при совпадении имён при копировании. У нас больше не будет такой сущности как «ФМ, который позволяет гибко настроить, какие файлы заменять при копировании», но будет сущность «специальная утилита для копирования, которая позволяет гибко настроить, какие файлы заменять при копировании, и которую можно использовать совместно с любым ФМ или даже просто вызовом из консоли».

Третье.

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

• stuurman — однопанельный файловый менеджер
• stuurman-desktop — утилита для отображения рабочего стола
• Форк gpicview (назовем его, условно, stuurman-image-viewer). Для чего это в просмотрщике: для отображения контекстного меню просматриваемых файлов.
• lxpanelx. Для чего это в панели: для контекстного меню на элеметах интерфейса, относяшихся к файлам (пункты dirmenu, например).
• Если будут ресурсы — также запилим и двухпанельный файловый менеджер.

Четвертое.

Однопанельник stuurman будет иметь:

• Полностью конфигурируемые хоткеи.
• Полностью конфигурируемое главное меню.
• Возможность запоминать отдельные настройки внешнего вида для отдельных каталогов.
• Библиотеки в стиле семерочного проводника.

Это не исчерпывающий список улучшений, просто основное, что вспомнилось из запланированного.

Пятое.

Я таки рассчитываю запилить собственный велосипед в стиле kparts, который позволит встраивать содержимое документа в окно ФМ (шире: в окно любого совместимого клиента). Граница между «окно файлового менеджера» и «окно приложения» станет весьма условна. Она будет зависеть от того, кому как удобнее организовывать рабочее место.

Шестое.

Данный стек технологий я рассчитываю дополнить протоколами для построения документо-ориентированного интерфейса. Самое основное, что нужно: протокол, который позволит отвечать на вопросы вида: «вот URI, открыт ли он в каком-то из окон как документ?», «вот окно, соответствует ли оно какому-то URI?», «какие URI в данный момоент открыты в окнах рабочего стола?» и т.п.

Совместно со всем вышеописанным, это даёт совершенно новые возможности построения графических сред и управления окнами.

А ты не форкай - велосипедь с нуля, забудь про dbus,libhal,fam и прочую фигню, не старайся осчастливить мир и в 6-7 месяцев уложишься.

Наркоманы ITT. :(

Я вот сейчас пошаманил с отложенной загрузкой информации о файле и снизил время открытия /usr/bin при «непрогретом» файловом кэше в несколько раз. :}

Мамонты вымерли, дружище anonymous. Так что свежего не будет. Догадайся откуда это.

static gboolean connect_to_fam()
{
#ifdef USE_INOTIFY
    inotify_fd = inotify_init ();
    if ( inotify_fd < 0 )
    {
        g_warning( "failed to initialize inotify." );
        return FALSE;
    }
    fam_io_channel = g_io_channel_unix_new( inotify_fd );
#else /* use FAM|gamin */

    if ( FAMOpen( &fam ) )
    {

Хде наркоманы ? Зря не слушаешь, реальные сроки называю.

зы. Ты же уже форкал этот писимэн ? Или на github не твой ,10 месяцев назад заброшенный, валяется ?

Хде наркоманы ? Зря не слушаешь, реальные сроки называю.

Я про «осчастливить мир». Нафиг мир, мне нужна удобная для себя среда. Другие люди в проект нужны лишь постольку, поскольку объем работы достаточно велик, и если кому-то нужна _такая_ _же_ среда, логично объединиться.

зы. Ты же уже форкал этот писимэн ? Или на github не твой ,10 месяцев назад заброшенный, валяется ?

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

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

А разве нужны такие агенты? mv, cp и rm уже есть. Далее, чуть выше вы пишете, что задачей libfm будет отвечать на вопрос о свойствах файла. Почему же окошко свойств не будет показывать та же libfm? Или её будет линковать внешняя утилита-агент? К тому же, придется организовывать межпроцессное взаимодействие между таким зоопарком агентов, а это также скажется на производительности.

Запили его на базе EFL для E17, чтобы в нём появился нормальный нативный FM, не всё же гномоподелием заниматься, надо делать ширше :)

А разве нужны такие агенты? mv, cp и rm уже есть.

Предлагаю ответить на такие вопросы:
1. Почему люди, которые используют для копирования утилиты с UI, используют именно их, а не cp?
2. Обязателен ли ФМ для того, чтобы запустить копирование файлов?

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

Потому что «окошко свойств» — это главным образом задача именно «нарисовать окошко», а не «определить свойства». И она никак не привязана к ФМ.

Внутри диалога «свойства» будут свои интерфейсные задачи, но с логикой _получения_ свойств они никак не связаны. С интерфейсом главного окна ФМ — тоже не.

Или её будет линковать внешняя утилита-агент?

Достаточно запустить некоторый бинарник.

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

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

Критичные к производительности места — это получение оглавления каталога и рендеринг его view.

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

Второе упирается в тормоза gtk, но на современном железе это не заметно. (Вот на Celeron D есть небольшая вялость интерфейса, да.) И в целом это не зависит от архитектуры ФМ: все приложения на gtk подтормаживают на рендеринге объектов типа icon view. Я планирую с этим немного побороться, если будет время.

Задачи же типа «дай мне контекстное меню для файла» к производительности не критичны, т.к. заведомо уложатся в приемлимое время отклика.

ranger

таки действительно годнота.

Проверяю отложенную загрузку mime type.

Каталог /usr/bin/ содержит 4105 объектов. (Из них 374 — символические ссылки.)
Время открытия на холодном кэше: 40 секунд без отложенной загрузки, 11 секунд с отложенной загрузкой.
Время открытия на горячем кэше: 1.5 секунды без отложенной загрузки, 1 секунда с отложенной загрузкой.

Каталог /usr/lib/ содержит 4499 объектов. (Из них 2373 — символические ссылки.)
Время открытия на холодном кэше: 14 секунд без отложенной загрузки, 8 секунд с отложенной загрузкой.
Время открытия на горячем кэше: 1.3 секунды без отложенной загрузки, 1 секунда с отложенной загрузкой.

Я бы предпочёл, чтобы оно показывало хоть что-то, но мгновенно. А потом добавляло файлы пачками, скажем, раз в секунду. Даже если это займёт в итоге больше времени, ощущения будут лучше. Ведь важна именно отзывчивость, а несколько задержек по 8 секунд могут взбесить. Да что там, даже 2 секунды иногда бесят.

Я бы предпочёл, чтобы оно показывало хоть что-то, но мгновенно. А потом добавляло файлы пачками, скажем, раз в секунду. Даже если это займёт в итоге больше времени, ощущения будут лучше. Ведь важна именно отзывчивость, а несколько задержек по 8 секунд могут взбесить. Да что там, даже 2 секунды иногда бесят.

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

Сделать stat на все элементы каталога — это практически мгновенно. (Запусти, например, PathFinder, который в составе fox toolkit. Он открывает каталоги мгновенно и без лишних перерисовок.) Тормоза возникают из-за того, что в том же цикле читается mime type и иконка.

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

Я вот сейчас сделал отложенную загрузку mime type, и время открытия упало с 40 до 11 секунд. Но для части файлов всё равно приходится читать mime type, поэтому не удаётся 11 секунд превратить в 1. Буду дальше работать над этим.

А добавление файлов пачками оставим для медленных ФС типа доступа по ftp. Локальный каталог должен открываться _сразу_.

Если сделать на /usr/bin свой кэш, хотя бы файл со строками «имя файла + тип иконки», иконки загружать сразу только видимые ,а остальные в фоне, то будет мгновенно работать.

Я так понимаю нужен идеологически верный товарищ со знанием C?

Понял. Интересное решение.

Почему все-таки gtk?

Почему все-таки gtk?

Я достаточно хорошо знаком с тулкитом, как в плане API, так и в плане внутренностей.

В перспективе, хотя боюсь не будет нужно, могу нарисовать морду на qt.

со знанием C

мда, смотрю в книгу - вижу...

GTK+, как я понимаю, второй?

Оба.

надеюсь там будет встроенный музыкальный плеер и генератор QR-кодов?

Лучше форкни Krusader, а то там что-то вяло как-то всё.

надеюсь там будет встроенный музыкальный плеер и генератор QR-кодов?

И в зависимостях потребует апач с пхп и мускл.

Очень неплохо было бы так: 1. Открываешь smb://geekless@se7en/C/users/geekless. Если я правильно понял - открытием занимается агент. Так вот, чтобы при открытии такой шары, после ввода логина и пароля эта шара монтировалась куда-то (через fuse например). Т.е. чтобы я мог открыть терминал и перейти в этот каталог, или по хоткею из ФМ открыть терминал в данном каталоге. Не знаю ни одного ФМ, в котором бы реализовывался данный функционал. 2. Мне кажется работа с архивами для пользователя таки может выглядеть, как работа с каталогами. Попытки так сделать есть в KIO, я думаю можно сделать лучше. Если я правильно понял - твоя архитектура позволяет для этого потом сделать отдельного агента, который would do the job?

<trollmode=off> Ну и напоследок. Как я понял ты - лучший знаток всея ЛОРа по GTK. Опять же, как я понял, ты в том числе недоволен третьей веткой GTK. Можешь объяснить конкретно, чем он тебе не нравится(не учитывая багов при прорисовке некоторых виджетов, т.к. это по сути мелочи)? </trollmode>

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

Программировать не умею, готов принять участие в тестировании.

есть желающие принять участие в проекте?

Где записаться?

Для меня, ленивой скотины, было бы предпочтительней работать по ТЗ типа: нужна функция some_mega_func(int a, char b), которая делает то-то и то-то и возвращает результат в <...>. Это не должна быть глобальная функция, а скорее локально-второстепенная. Я не смогу написать сходу display_fm_with_many_lolypops(), но вполне осилю [за раз] какой-нибудь qsort() :).

Очень неплохо было бы так: 1. Открываешь smb://geekless@se7en/C/users/geekless. Если я правильно понял - открытием занимается агент. Так вот, чтобы при открытии такой шары, после ввода логина и пароля эта шара монтировалась куда-то (через fuse например). Т.е. чтобы я мог открыть терминал и перейти в этот каталог, или по хоткею из ФМ открыть терминал в данном каталоге. Не знаю ни одного ФМ, в котором бы реализовывался данный функционал. 2. Мне кажется работа с архивами для пользователя таки может выглядеть, как работа с каталогами. Попытки так сделать есть в KIO, я думаю можно сделать лучше. Если я правильно понял - твоя архитектура позволяет для этого потом сделать отдельного агента, который would do the job?

Вообще-то не нужно ничего изобретать. gvfs это умеет из коробки.

Открываю в файловом менеджере ftp://ftp.debian.org/ , тыкаю Инструменты -> Терминал, открывается терминал с каталоге /run/user/1000/gvfs/ftp:host=ftp://ftp.debian.org

Опять же, как я понял, ты в том числе недоволен третьей веткой GTK. Можешь объяснить конкретно, чем он тебе не нравится(не учитывая багов при прорисовке некоторых виджетов, т.к. это по сути мелочи)?

Лично для меня нет разницы, о обоих тулкитах кривоват рендерер, в обоих тулкитах есть одни и те же архитектурные проблемы. В gtk3 отрисовка тормознее и в css черт ногу сломит, но это к программированию отношения не имеет. Но с gtk3, вообще говоря, моё знакомство только теоретическое — изучение документации и сорцов. Вся моя практика с 3-й версией на данный момент — портирование туда gpicview.

lxpanelx я собираюсь портировать на gtk3, но и с двойкой буду тянуть совместимость еще пару лет, как минимум. Ну или до тех пор, пока в gtk3 не исчезнут проблемы с темами оформления.

ты б еще написал в профиле URL на гитхаб проекта или свой джаббер, т.к. твой блогспот анально огорожен то легиона.

Я как сделаю сайт под проект, оповещу общественность через ЛОР.

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

Где записаться? Для меня, ленивой скотины, было бы предпочтительней работать по ТЗ типа: нужна функция some_mega_func(int a, char b), которая делает то-то и то-то и возвращает результат в <...>. Это не должна быть глобальная функция, а скорее локально-второстепенная. Я не смогу написать сходу display_fm_with_many_lolypops(), но вполне осилю [за раз] какой-нибудь qsort() :).

Это отлично! :}

«Записаться» можно будет на гитхабе. Когда выложу сорцы на гитхаб, напишу в треде.

«Записаться» можно будет на гитхабе. Когда выложу сорцы на гитхаб, напишу в треде.

Это зело неанонимно! И кто (и, главное, как) мне будет на гитхабе давать мини-задания?

Ну тогда пиши на почту. igeekless@gmail.com

Это зело неанонимно

Создай отдельный аккаунт для этого. Настоящее имя не обязательно.

И кто (и, главное, как) мне будет на гитхабе давать мини-задания?

Различные issues. Выбрал понравившуюся, прикрепился, сделал, закрыл.

перспективней было бы выбрать Qt, но это твоё дело

ждем stuurmanwm.