Исследуется необходимость в еще одном файловом менеджере

Среди найденных и опробованных у всех оказались довольно неприятные недостатки

И один фатальный.

У многих программистов наступает момент, когда они начинают писать свой ФМ. (я уже прошел его).

Люди говорят нужно. Лишним не будет, пишите.

Ссылку на гитхаб/ведро помести. Может кто еще захочет.

Не нужно. Проблемы типа «прибит гвоздями к kde-runtime» волнуют только идиотов (aka тулкитофобов), а mc уже давно идеален.

Уже существует dolphin.
Чем он не угодил?

Крестоносец рвёт всех!
Перешёл на кеды в основном, из-за него, хотя, корица меня вполне устраивала.

Хорош, не спорю. Но Krusader лучше.

Он не является полноценным двухпанельным, и опять же KDE (не нужен)

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

может необходимость этого мне только кажется и будет еще одно ненужно?

А что на ЛОРе нужно то? Смайлики и карма?

похожий на виндовый Total Commander

Давай уделаем TC. Давай запилим такой ФМ, чтобы на нём делали, например, импорт патчей из git'а. Представляешь, у тебя на одной панели коммиты git, а на другой ФС. Ты такой коммит выбрал и копируешь в патч. А потом открыл свой репозиторий и патчи туда засовываешь.

У многих программистов наступает момент, когда они начинают тешить свой ФГМ.

пофиксено

Worker не смотрел? Стремноват, конечно, но зато afaik только xlib ему и нужен.

з.ы. а вообще не заморачивайся, если желание есть - возьми и сделай :)

Вопрос собственно: может необходимость этого мне только кажется и будет еще одно ненужно?

Либо он нужен лично тебе и тогда тебя не волнует чужое мнение, либо он никогда не будет написан.

Или открываешь картинку, включаешь плагин (ака костыль) для импорта туда файлов, открываешь её, как каталог и тупо на F5 их туда. И делать, такие плагины, чтобы мог любой школьник у себя.
Или вообще пилишь плагин для базы данных и копируешь туда-сюда таблицы/процедуры/вьюхи в своём ФМ.

Пиши

прибит гвоздями к kde-runtime

Так возьми код и помоги, как раз тот же C++ с кутями будет.

Надо подумать над этим.

В чем помощь, если его сознательно делали на kde и для kde?

Worker не смотрел?

Концепция интересная. Надо по разбираться. Тулкит походу морально устарел. Сразу заметил, то не умеет в модальне окна.

Когда разработчик работает над нужным в первую очередь лично ему проектом, часто получается что-то годное, но если ты сам своим детищем пользоваться особо не собираешься, то начинать точно не стоит. Писать велосипеды в качестве хобби - это вполне нормальное для программиста занятие, если не получится ничего путного, так хоть опыта наберешься. Кроме того, большинство существующих проектов (кроме первопроходцев) начинались как велосипеды. Не ориентируйся ни на кого, тебя просто обосрут и этим все закончится. Только если соберешься браться за эту задачу, взвесь свои способности к самомотивации. Могу по своему опыту сказать, что каким бы интересным и нужным ни был проект, где-то через 4 недели работы в одиночку начальный запал закончится и возникнет большой соблазн сделать паузу (или ее вынудят сделать обстоятельства). После продолжительной паузы бывает сложно себя заставить вернуться к работе, а заброшенный проект не нужен ни тебе, ни другим.

Либо он нужен лично тебе и тогда тебя не волнует чужое мнение, либо он никогда не будет написан.

+1

Сделать ядро, т.е. механизмы отображения, вывода и передачи комманд, а все остальное вплоть до вывода содержимого каталога лепить на внешние модули/ПО. А ядро - только прослойка между системой вывода/ввода (QT) и плагинами. То есть: /[g/]ui (QT/gtk/ncucses (кто что захочет)) <-> ядро <-> исполнители (плагины/либы/любой изврат). Главное - простые и понятные интерфейсы всем между этим. И все. Один пишет гуи, другой костыли.
А если будет все-в-одном, то это будет очередной комбайн в коде которого никто не захочет разбираться.

Ну так kde5 на подходе, с нормальными либами.
В любом случае это рациональнее чистого Qt и «нового проекта».

Очень вкусная штука.

Если так кодить хочется, не лучше ли к имеющимся проектам что-то дописать ?
Про фм дольше говорить, чем его делать (речь о функциях именно фм) - в лазаре за пару минут можно натыкать 2 StringGrid'a и ряд кнопок+час на их заполнение и навигацию и за полчаса накодить функционал f4-f8. Т.е. делов на пару часов.
Остальные свистелки, непосредственно к фм, отношения иметь не будут.

Я в за советы crutch_master'а. Убогих и урезанных подобий totalcmd полно, а вот как раз какой-то базы для простого увешивания своими скриптами на питоне не хватает.

Надо чтобы все меню были как у опенбокса — в текстовом формате (только не в XML) и с пайпами. Чтобы кнопки любые назначались, чтобы панелей бесконечное количество можно было вешать, чтобы они появлялись по определённому событию.

А то вон добавляют какие-то паршивые меню действий, состоящие из долбаных .desktop-файлов, делают меню на полэкрана с бесполезными пунктами, дублирующими горячие клавиши…

Порви их всех.

Northern Capitan не?
http://freecode.com/projects/xnortherncaptain
Двухпанельные нафиг не нужны. Нужен аналог NextStep роллера.

Чем не угодил spacefm?

Нужно.

Вопрос собственно: может необходимость этого мне только кажется и будет еще одно ненужно?

пиши, почему нет?

Идея и интерфейсами такая. Ядро запускает гуй и слушает его выходной поток. Гуй запускается и отправляет ядру запрос на структуру, например, домашнего каталога, например, в json там содержится: тип запроса и каталог. Ядро «парсит» json ищет плагин для данного типа запросов, запускает его и передаёт ему каталог, например, в качестве параметра (в отдельных случаях можно также гонять, например тот же json через поток). Плагин передаёт что надо ls, парсит его, записывает результат опять же в json, например, и отправляет обратно. Ядро пересылает ответ (или ошибку) гую. Гуй парсит/выводит/кеширует делает что хочет. Если я хочу скопировать, то делаю тот же cp/dd слушаю выходной поток и рисую progress bar. Возможно это будет не очень быстро, но зато очень гибко.

Файловые менеджеры не нужны, только консоль.

То есть: /[g/]ui (QT/gtk/ncucses (кто что захочет)) <-> ядро <-> исполнители (плагины/либы/любой изврат). Главное - простые и понятные интерфейсы всем между этим. И все. Один пишет гуи, другой костыли.

плюсую. Например я не видел ФМ, который умеет xattr. Дельфин привязывается к СУБД в кедах, а она жутко тормозная и жутко тяжёлая(если вправду все 100500 файлов проиндексировать). Зачем это надо, если есть xattr? Или например удобное шифрование (плагин-прокладка между ФМ и GnuPG). Да и много чего ещё можно сделать. Вот только одному это не осилить, но если будет ядро с вменяемым API, то народ подтянется. Будет Over9000 костылей на все случаи жизни, НО, каждый пользователь будет выбирать только нужные ему.

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

именно так.

Ну, если такого нет, то почему бы и не сделать? Надо лишь хорошо продумать взаимодействие компонентов, написать стандарт, да пилить потихоньку модули с ядром. Главное стандарт хороший а там - говнокод в ядре - сменил ядро, говнокод в gui - сменил его. Гавёный плагин - написал свой. Стандарты одни - никто ничего не заметит.

Я не очень большой эксперт, но json, для парсинга вроде не плох. Либы для него везде есть, поля добавлять легко. Гоняй его туда-сюда через stdin/stdout, да разбирай. Единственное но - бинарные данные.

Файловые менеджеры не нужны, только консоль.

ты ещё скажи: никакие файлы не нужны, только plain-text ASCII. Только скажи это где-нить не здесь, а там, где твой plain-text. Ну и из консоли конечно.

А здесь ты не нужен.

Я не очень большой эксперт, но json, для парсинга не плох.

почему нет? Пусть будет json, он везде есть вроде-бы.

Возможно будет проще не писать с нуля, а отвязать Krusader от kde-runtime

Плагин передаёт что надо ls

не, ну это уж ты через край хватил. man 3 readdir и man 2 stat.

Возможно это будет не очень быстро

нормально.

Проблемы типа «прибит гвоздями к kde-runtime» волнуют только идиотов (aka тулкитофобов)

Не путай kde с тулкитом. Если в qt засунут всякие непомуки, он тоже станет ненужен.

Либо он нужен лично тебе и тогда тебя не волнует чужое мнение, либо он никогда не будет написан.

Правильный подход. Чеши где чешется, остальное за зарплату.

Почему для архивов и всяких ftp везде используют плугины, а не монтирование? У тебя есть шанс это исправить.

Надо подумать, что может понадобиться. Так-то вроде просто все, а как начнешь делать.
Запрос-то простой: кто делает, что делает, где делает. Ответ тоже, по большей части, что, список полей, набор значений.
Например:
Запрос: fs_plugin, ls, хомяк. Ответ: список, [имя файла, размер], [[имя,размер],[имя,размер],...]
Запрос: fs_plugin, cp, источкик, получатель. Ответ: (потоком) прогресс из (cp|pv) {тип:progress_bar;всего:x bytes;скопировал:x bytes}
Запрос: db_plugin, select, db_name. Ответ: список, [имя таблицы, размер] ...
etc...
Что еще может быть?

ftp

ЕМПНИ для ftp можно примонтировать.

Два чаю этому благородному дону!
На хрена изобретать велосипед, если можно допилить уже существующий?!

Если в qt засунут всякие непомуки, он тоже станет ненужен.

форкнем, когда(и если) засунут.

Ответ: (потоком) прогресс из (cp|pv)

ответ — число скопированных байт. Пусть гуй сам думает.

А для этого нужен ещё размер выделенного в источнике. Т.е. если в источнике 1000Мб выделено, и скопировано 100Мб, то гуй должен рисовать 10%. Ещё имена файлов, которые копируются, нужно отдавать гую. Ещё копирование должно быть отдельным процессом вместе со своей табличкой.

На хрена изобретать велосипед, если можно допилить уже существующий?!

ТС хочет изначально двухпанельник, а не проводник с фичей «разделить окно попалам».