Файловый менеджер на C++/Qt

или предложите идеи

1. https://github.com/VioletGiraffe/file-commander (C++/Qt)
2. Посмотреть на Worker, и портировать его на Qt. Отправить автору патч. :)

Все операции выполняются через стандартные утилиты GNU/Linux – cp, mv, rm

Ох это плохая идея. Как минимум, ты не можешь статус копирования файлов отслеживать таким образом. Лучше уж std::filesystem возьми, раз уж у тебя плюсы.

P.S.

qt5-base

Ну и это… Qt6 уже давно все используют.

Я традиционно буду ругаться на sudo make install. Есть checkinstall для простого опакечивания.

Молодец, чо. Не забрасывай проект только.

Все операции выполняются через стандартные утилиты GNU/Linux – cp, mv, rm,

Тээээкс. Делай без них, на нафига лишняя просрочка…

Интерфейс я бы советовал делать на qml.

Интерфейс я бы советовал делать на qml.

А я, наоборот, за виджеты. ФМ это одна из тех программ, которые чем легче и предсказуемее, тем лучше.

Ну и это… Qt6 уже давно все используют.

Это как раз некритично, Qt4+Qt5+Qt6 на одной кодовой базе вполне можно организовать.

Хотя файловых менеджеров и так пруд пруди, не останавливайся. Приятно, что декстопные приложения все еще делают не на электроне.

Все операции выполняются через стандартные утилиты GNU/Linux – cp, mv, rm

или предложите идеи!

Проверить на работу c русскими-китайскими-арабскими буквами и файлами со странными и необычными символами в именах.

Уж прости, но такое себе. Хотя всё же как первый крупный проект самое то.

Ну и это… Qt6 уже давно все используют.

Это как раз некритично, Qt4+Qt5+Qt6 на одной кодовой базе вполне можно организовать.

Ты сам-то пробовал портировать код с Qt4 на 5 и на 6? Там достаточно изменений, чтобы осознать бестолковость этой идеи.

«киллер-фича» (от английского «killer feature») какая? без нее не интересно. я планирую с mc перейти на far2l.

Я согласен про легковестность. И раньше я бы все делал на виджетах. Однако последние несколько лет я пишу исключительно на Qml и могу сказать: оно достаточно быстро. Да, виджеты быстрее, но разницы толком не заметно, если специально не всматриваться. К тому же ощутимые тормоза делают не сами виджеты или qml как таковые, а неоптимальные алгоритмы внутри своей программы, когда в результате того, что какая то операция выполняется в ui потоке, этот самый ui лагает.

А вот если сравнить именно возможности, то qml позволяет все разрабатывать быстрее, и проще. Кроме того какие то кастомные задачи, кнопочки, всплывающие панели и т.п. - это вообще на раз. Резиновые интерфейсы, управление размещением - все это и многое другое делается моментом. И ещё, качественная поддержка тем и встроенные нормальные темы светлые и тёмные (material) и лёгкость создания своих.

Так они же там целенаправленно и последовательно ломали API переименовывая enumы, классы и функции — because reasons.

Чюдесные линуксовые GUI используют консольные архиваторы и ничего…

И не от хорошей жизни они это делают. Но вообще, есть libarchive.

Не поверишь, там начнётся трэш из знаков вопроса ))

А я до оформления поста доколупаюсь. Второй и четвёртый скриншот — для тех, кто не умеет кликнуть по первому и третьему? Или в датах «креадет, модифаед, аксессед» какой-то сакральный смысл, что их надо на пол экрана отдельными картинками?

Встрой фичу по «плавному» копированию на флешку.

Когда починят «ускоренное» копирование файлов в Linux? (комментарий)

Но сначала надо прогресс-бар, конечно, сделать.

я планирую с mc перейти на far2l.

А какая «киллер-фича» в данном случае?

Ты сам-то пробовал портировать код с Qt4 на 5 и на 6? Там достаточно изменений, чтобы осознать бестолковость этой идеи.

Нормально всё. При этом, ещё не на всём актуальном старье есть Qt6.

Все операции выполняются через стандартные утилиты GNU/Linux – cp, mv, rm

Ох это плохая идея. Как минимум, ты не можешь статус копирования файлов отслеживать таким образом. Лучше уж std::filesystem возьми, раз уж у тебя плюсы.

Так ему есть куда развиваться. Работающие заглушки сделал.

я планирую с mc перейти на far2l.

А какая «киллер-фича» в данном случае?

знакомые клавиатурные сокращения. они более развиты чем в mc. я начитал еще с norton commander. потом перешел на far. для него даже написал простой плугин. может для far2l тоже напишу. только пока не знаю какой. на вскидку можно переписать на rust) или обновить версию ssh.

Очень достойный проект, даже для опытного разраба, а вы как говорите начинающий. Так держать. 👍

Традиционный вопрос: как там в фаре со списком избранного? Всё те же 10 хоткеев вслепую? Или что-то новое придумали? В mc Ctrl+\ неидеален, но намного, намного лучше.

В свою очередь, в фаре работа с архивами информативнее, чем в mc. Идеала нет.

С разморозкой. У меня 4 и 5 поддерживаются совершенно равноправно, условных компиляций – минимум. И единая кодовая база – это не «портировать», портировать – это когда с 3 на 4 переходили.

С шестёркой несколько сложнее, там злобные буратины окончательно сломали QTextCodec (точнее, он остался в модуле совместимости, но понятно, что не позднее 7.0 его уберут). Поэтому скорее всего, напишу враппер на десяток строк. Благо, в 6.4 кутешники дали задний ход и поддерживают все кодировки, предусмотренные в ICU, после чего смысл отказа от QTextCodec был окончательно утрачен. :) Остальное и так работает.

Also, редактор TEA от roxton поддерживает 4, 5 и 6.

Не каждый проект, конечно, можно так легко поддерживать. У кого была привязка к QtWebKit – тому не повезло.

Буду рад, если … предложите идеи!

Иногда переключаюсь с графического файлового менеджера на vifm из-за того, как в vifm сделано массовое переименование:

• выделил несколько файлов.
• выполнил встроенную команду :rename
• оказался в редакторе vim, в котором каждая строка — имя файла. Можно пользоваться всякими возможностями, например массовой заменой или блочным выделением.

Когда случается пользоваться macOS или Windows, в тамошних дефолтных ФМ не хватает умения работать с симлинками. До недавнего времени не было табов. Возможности к которым так привык, что ожидаю видеть их везде.

Не проще ли копирование по алфавитному порядку? Или fatsort прикрутить?

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

У тебя, видимо, не особо сложные проекты.

Define сложность. Ну если не считать проприетарщины по работе, у меня как минимум полтора проекта в опенсорсе, про один из них была пара новостей на ЛОРе, легко находится (второй пока в глубокой альфе), да хоть в профиль мой загляни. Да, это не браузер и не офисный пакет, но и далеко не хеллоуворлд.

Благо, это и не требуется никогда.

Для копроразработки «выпустил, плюнул, забыл» – да, не требуется. Только не надо распространять это на все юзкейсы и говорить про «бестолковость затеи». Иногда это просто чья-то криворукость. Ну или что-то очень специфическое, да: я про QtWebKit/QtWebEngine уже упоминал. Только у нас тема про файловый менеджер, а там от гуя нужна в первую очередь отзывчивость (не дай бог, провалишься в Каталог Тысячи Файлов), и никакой вебенджин лично я бы туда не потащил.

можно офигеть если поддерживать больше одной версии сразу

Если программа так изначально писалась – охотно верю.

Выглядит красиво. Как владелец не крутого железа, искренне прошу не обновляться на QT6

Очень здорово, удачи тебе, только почему через утилиты, а не через системные вызовы?

Я б ему, как уже написал выше, предложил не обновляться и не «не обновляться», а просто поддерживать обе мажорные версии. Пишем на меньшей, периодически проверяем собираемость на большей. Иногда это может привести к необходимости влепить условную компиляцию, но таких случаев гораздо меньше, чем могут предположить люди, регулярно читающие новости «программа XXX переведена на Qt6, поддержка Qt5 немедленно прекращена».

???

Ты точно прочитал тему по ссылке?

Когда починят «ускоренное» копирование файлов в Linux?

Нужны вкладки !

или предложите идеи

Показывать размеры файла или число объектов в папках в главной области. Очень полезная фича, по факту её умеют только 2 файлменеджера - Дельфин и Наутилус с форками.

ужасная аватарка

Показывать размеры файла или число объектов в папках в главной области. Очень полезная фича, по факту её умеют только 2 файлменеджера - Дельфин и Наутилус с форками.

Согласен + размер каталогов

У меня на винде OneCommander показывает.

в гитхабе у вас сначала «4 Run the application» потом «5 Optional: Install as a system-wide binary» думаю что логика здесь нарушена. люди сначала инсталлируют потом запускают. если не хотите инсталлировать в систему то переместите в место запуска от пользователя. например в каталог ~/bin .

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

Традиционный вопрос: как там в фаре со списком избранного? Всё те же 10 хоткеев вслепую? Или что-то новое придумали?

я избранным не пользуюсь. мне хватает истории пользования. давно ставил плугин избранного. там вызов содержимого избранного был по цифрам от 1 до 0.

я только поставил far2l более точный ответ дам после некоторого времени использования. на вскидку в меню появилось Location menu куда можно добавлять позиции. тоже типа избранного и вызов по цифрам от 0 до 9 .

сделать 2 панели, переписать на руст

Ну, как ФМ-мописец я понимаю твою увлеченность. Но все же покритикую глядя на скриншоты:

1. Size - измеряется в мегабайтах, гигабайтах. Не в item'ах, уж точно. И уж точно у тебя на скрине не 6 items;

2. Где кнопка вверх, или хотя бы назад? Как вариант, две точки, если ФМ у тебя нажимабельный?

3. Где файлы? Хочешь сказать у тебя в хомяке нет ни одного файла?

4. Выполнение через стандартные утилиты - говно. Ты не сможешь адекватно отслеживать состояние процесса и не сможешь адекватно обрабатывать ситуацию. Пример: ты начал копировать файл размером 10 Гб на раздел 11 Гб, переключился в другое окно, и создал на этом разделе файл в 5 Гб. Твой ФМ выдаст тебе сообщение, что закончилось место? Вот посмотри как у меня: https://i.ibb.co/XTLbxFg/Peek-2025-12-24-04-10.gif - даже в системную иконку могу рапортовать количество скопированного;

5. Когда работаешь с файлами больше чем раз в неделю - анимации и плавные переходы раздражают;

6. Будет красивее, если папкам из XDG назначишь свои иконки. Их ты можешь получить из ~/.config/user-dirs.dirs;

7. Строя UI, представляй себя в автомобиле за рулем, где важнейшие элементы выноси в зону видимости, а второстепенные вроде кнопки открытия багажника, прячь. Change theme это конечно хорошо, но все же переход на уровень вверх - лучше;

8. Концепция ФМ уже давно разработана, и по моему ИМХО есть смысл ей следовать. В окне слева устройства, диски, папки быстрого доступа и избранные. Снизу - строка статуса.

- - -

Как заслуженный велосипедист всея ЛОРа, могу тебе порекомендовать сперва выбрать путь, а затем строить ФМ, следуя ему: путь проводника - красивой удобной мышевозной штуки, с drag&drop и эффектами; путь файлового менеджера, типа FAR, Total и тд - фичастой мастхев штуковины для бородатого сисадмина, управляемой клавиатурой, маленькой и быстрой.

Поддерживаю твои начинания !

А в чëм его прикол? Особенность? Отличительная черта?

Ненужно, странно, вырвиглазно. Вобщем всё как мы любим! Держи лайкос!

1. Да, отчасти ты прав, но есть нюанс. В каталогах у меня понятие «Items», а в файлах как раз привычные гигабайты и мегабайты, т.к, чтобы измерить настоящий размер папки(а не 4 КБ, как это измеряется по дефолту), надо рекурсивно узнавать размер элементов внутри каталога.
2. Кнопка назад и вперёд у меня в виде зелёной стрелочки, ведь нормальных иконок я пока не нарисовал. Вариант хороший, думаю даже в следующем обновлении добавлю.
3. В Home у меня только скрытые файлы, не вижу смысла в корневой директории юзера хранить что-то, кроме директорий(и как раз нужных файлов в них) и скрытых файлов, которые часто системные.
4. Да, тут ты прав, в файловом менеджере действитетльно это может показаться плохо, в следующих обновлениях буду переписывать хотя бы на утилиты Qt.
5. Там нет прям таких анимаций как ты говоришь. Я просто сделал плавнее переходы между каталогами и сделал плавнее открытие контекстного меню, иначе большинству людей просто резало бы по глазам из-за резкости.
6. В будущем я всё равно буду рисовать свои иконки, но, временно могу воспользоваться и ими, спасибо за совет.
7. В будущем планируется вынести в отдельное меню настроек, куда также перенесётся и настройка показа скрытых файлов.
8. Ну как тебе сказать, для меня это что-то между пет проекта и тем, чем я в будущем буду пользоваться. Так что не почему бы не выложить сюда?

Отвечу прямо. Ничем. Для меня это что-то между пет-проектом и тем, чем я буду пользоваться.

Что вы имеете в виду под «знакомые клавиатурные сокращения»? ^C, ^V, F2? Всё это будет в следующем обновлении, ведь мне было не до этого, ведь надо было нормализовать работу всего функционала ФМ

могу тебе порекомендовать сперва выбрать путь

Мой путь лёг навсегда на C/C++ и Python. Да, может у меня и будут второстепенные языки для чего-то, но C/C++ и Python мои главные языки

А как там с разделением логики и представления, как организуется взаимодействие? Я сам давно пишу на Qt, используя виджеты, вроде и интересно было бы QML посмотреть, но непонятно, как увязать логику, которая использует свои структуры данных с представлением на жаваскрипте.

Вот тебе идеи из того что плохо работает в текущих:

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

Вообщем как обладатель больших (очень) фото архивов я в целом не доволен текущими файловыми менеджерами под линухом, а как хранящий часть на самбе - и Маковским тоже 🫤