LINUX.ORG.RU

Файловый менеджер моей DE

 


1

1

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

Последнюю неделю посвятил дописыванию ФМа, после которого сделаю пару косметических допиливаний и раздам вам на поругание в виде установочного скрипта, пока только для DEB-based. Собственно оно уже устанавливается и работает.

Итак, ФМ. Что мы уже умеем.

Ходить по директориям. Наверное после создания ГТК-шного интерфейса с его деревянной иерархией, это второе что вызвало у меня сложность, а открывать чужие коды не хотелось. Номинально, когда мы заходим в симлинкованную директорию, а потом выходим из нее вверх двумя точками — мы должны попадать в родительскую директорию оригинала. Красиво — попадать в ту директорию откуда мы зашли.

Тривиальные операции с файлами. Создать, копировать, вырезать, вставить, переименовать, свойства и тд. Не знаю как ФМ выводят индикатор прогресса в докбар или панель задач, но я решил просто добавлять этот индикатор к иконке окна. Выглядит красиво.

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

Устройства. Монтирование, размонтирование, краткая статистика.

Превьюхи. Их можно делать для картинок и для видео + в настройках опция ограничителя пока задана жестко, но со временем изменю на плавающее значение. Кстати для видеопревьюхи берутся кадры из 10%, 50% и 90% таймлайнов, из них выбирается тот на котором самая большая разница между светлыми и темными пикселями. Найду способ отображать GIF'ы — сделаю вообще динамичные.

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

Сортировки, просмотр свойств, тоже работают.

Интеграция. Настройки ФМа вынес в Панель Управления. Разумеется они доступны из самого ФМа по кнопке. Добавил в ФМ поддержку фишки DE, названную «Уровень быстродействия». Ее суть состоит в том, что в зависимости от выбранной в системных настройках степени (выкл-мин-макс), в системе общеглобально изменяется использование спецэффектов, удобств, прозрачностей, частоты опросов и прочих свистоперделок. Например при максимальной степени быстродействия, ФМ не создает превью, не анимирует операции, не следит за инотифаем, операции делает в один поток, и вообще старается лишний раз не дергать файловую систему.

На данный момент код занимает 1024 строчки основной программы, 768 строчки либы поддержки (тривиальные функции, не имеющие отношения к алгоритмам ФМ), 16 строчек CSS-кода и 128 строчек занимает плагин к панели управления.

Готов ловить помидоры.

★★★★★

Проверено: hobbit ()
Последнее исправление: dataman (всего исправлений: 3)

Прозрачная панелька - зачет, но приложения не по центру панельки. В глаза бросается

Parthen ★★
()

Устройства. Монтирование, размонтирование, краткая статистика.

Что насчёт всяких Яндекс и Гугл дисков?

u-235
()

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

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

Прозрачная панелька - зачет, но приложения не по центру панельки. В глаза бросается

Поработаю над этим. Дело в том что «центр панельки» - понятие растяжимое.

Приложения в центре, но в центре области которая осталась после размещения других объектов - меню, трея и тд.

windows10 ★★★★★
() автор топика
Ответ на: комментарий от u-235

Поиск по файлам есть?

Нет.

Хотя + за идею, добавлю !

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

Да, это прям настоящая виндузятская привычка :)

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

Скажи, это все ещё на php?

Да. И к сожалению на кастомной версии собранной с необходимыми модулями. Пых позволяет писать собственные модули на С\С++, после чего этот С-шный код может использоваться напрямую в PHP.

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

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

kma21 ★★★★
()
Ответ на: комментарий от u-235

Что насчёт всяких Яндекс и Гугл дисков?

Еще не разбирался, но по идее это не очень сложно, если найду способ монтирования этого всего.

windows10 ★★★★★
() автор топика

Не создавать предпросмотр для файлов больше 1Мб

Может дать пользователю инпут чтобы он сам мог решить больше скольки ему нужно? А то как-то совсем не юзерфрендли получается.

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

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

На самом деле бардака здесь нет. Его вносят scrot'овые скриншоты, которые я оставил чтобы было что показывать в качестве содержимого =)

windows10 ★★★★★
() автор топика

Ну молодец, чо.

А теперь посмотрим, строк сколько занимает настоящий минимально юзабельный ФМ с многопоточностью и всем остальным, который не зависнет на открытии каталога с 100 000 картинок.

Первый вариант:

Второй вариант:

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

А зачем, если у человека порядок в голове? Это странно, но для одних людей порядок на столе как-то отражается порядком в голове, а у других такой порядок вызывает затруднения и понижает эффективность.

papin-aziat ★★★★★
()
Ответ на: комментарий от kma21

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

Нет, так оно не работает.

Здесь оно работает примерно по аналогии с <span> или <div> в HTML - блочно, и центровка происходит по родительскому блоку.

Я пытался делать «по центру», но для этого учитывалась ширина других блоков, и иконки мерзко меняли свои координаты, когда в трей что-то добавлялось или удалялось.

Надо подумать =)

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

А теперь посмотрим, строк сколько занимает настоящий минимально юзабельный ФМ с многопоточностью и всем остальным, который не зависнет на открытии каталога с 100 000 картинок

Да, десятки тысяч строк.

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

Что касается открытия каталога с 100 000 картинок - то например LXDE-шный PcmanFM подвисает. Даже на тысяче. Мой - нет. А в целом разницы никакой нет, потому что и PHP и С дергают один и тот же системный вызов.

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

А в целом разницы никакой нет, потому что и PHP и С дергают один и тот же системный вызов.

Ты код-то хоть покажи. Что вы там дергаете. Что PcmanFM дергает, я видел.

например LXDE-шный PcmanFM подвисает. Даже на тысяче

Мой не подвисает, я дорабатывал кодовую базу PcmanFM-а. Долфин тоже виснуть не будет, но там кода еще больше.

wandrien ★★★
()
Ответ на: комментарий от papin-aziat

А зачем, если у человека порядок в голове? Это странно, но для одних людей порядок на столе как-то отражается порядком в голове, а у других такой порядок вызывает затруднения и понижает эффективность.

вызывает затруднения

Затруднения в чём? Найти нужную вещь/файл/папку?

понижает эффективность

Понижает эффективность чего? Когда у тебя всё структурированно, разбито по категориям - это понижает эффективность?

P.S. К @windows10 это не относится, т.к. «На самом деле бардака здесь нет. Его вносят scrot’овые скриншоты, которые я оставил чтобы было что показывать в качестве содержимого»

basilic ★★
()
Последнее исправление: basilic (всего исправлений: 1)

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

Но за то, что не просто болтаешь, а что-то делаешь, причём как-то работающее — однозначный зачёт!

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

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

Что сразу не Basic?

А если серьезно, то почему не C/C++, Pascal, Rust, то есть нормальные компилируемые языки, негоже что бы DE тормозил.

А вот PHP не для этого был создан. Изначально он был препроцессором HTML

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

Да. И к сожалению на кастомной версии собранной с необходимыми модулями. Пых позволяет писать собственные модули на С\С++, после чего этот С-шный код может использоваться напрямую в PHP.

Слабый аргумент в пользу PHP

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

Какая разница чем он был изначально? Изначально С был создан как минимально-юзабельный язык для PDP, пора бы уже на свалку, не?

Тебе кстати хорошо ответили, но не программируя на этом божественном языке, трудно этот ответ понять. Массивы-словари и способы их обработки это нечто, смотреть нужно на сборник функций array_*. В язык встроено множество функций для IO которые отвечают современным запросам, что было темой какого то треда windows10.

Скорость у PHP просто замечательная, намного лучше чем у Python. А в новых версиях еще и JIT повезли, до этого его вообще не было, и то очень хорошо оптимизировали.

Язык так же более современен чем C, Pascal, или такое убожество как Rust. Есть GC, возможность указать что значения не является nullable, генераторы, зеленые потоки.

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

Какая разница чем он был изначально? Изначально С был создан как минимально-юзабельный язык для PDP, пора бы уже на свалку, не?

Скажи это системный программистом, программистам которые пишут код для микроконтроллеров, он так же ядро линукса пишется на C, там, конечно пытались rust запихнуть, но как оказалось он для это не предназначен, да и сложность с его внедрением много, а желающих нет.

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

Могу отзеркалировать твой комментарий, покажи сотни, тысячи, миллионы сайтов и CMS которые написаны на С. Не осилили, вот PHP другое дело. Я сути твоего комментария не понял. Что это должно показывать или доказывать?

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

такое убожество как Rust

Тиха а то набигут тут всягие сведетили раста

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

Что-то мне VK вспомнился, который написан на C++.

Они и Facebook два крупных потребителя PHP-лакомства, настолько крупных, что они написали свои реализации PHP: https://github.com/VKCOM/kphp

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

Могу отзеркалировать твой комментарий, покажи сотни, тысячи, миллионы сайтов и CMS которые написаны на С. Не осилили, вот PHP другое дело.

PHP изначально создавался для веба, а C для прикладного назначения, и на нем был переписан UNIX который изначально был на писан на B предок BCPL, давай от этого отталкиваться прежде чем что-то писать.

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

У php есть проблема для применения в качестве языка десктопных приложений – он сам создан и существует как «приложение» в определённой нише, а не как универсальный ЯП для произвольных задач. Это чисто практическое неудобство, связанное с экосистемой языка.

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

Мне тут вспомнилось. На канеле Ильдар Автоподбор есть такой электронщик Олег, который помогает им чинить машины. В одном из видео, когда надо было проанализировать данные с осциллографа, было видно, что он на PHP скрипт пишет. В принципе, почему бы и нет, для локальной задачи любой ЯП сгодится.

(Там, кстати, забавный момент был. В комментах под видео его залошили за PHP, так в следующей серии он на Перле скрипт написал. Видимо, старой школы мужик – никаких вам Растов.)

Массивы-словари и способы их обработки это нечто, смотреть нужно на сборник функций array_*.

Жутко неудобные костыли. Код с ними выглядит неопрятно. Это может выглядеть хорошо только в случае, если это твой первый скриптовый язык после Си-Паскалей в институте, и ты при виде этих массивов словил вау-эффект. А так взять тот же Ruby – там намного удобнее работа с массивами и любыми итерируемыми сущностями.

А из современных ЯП, если наверное взять какой-нибудь Zig, то вряд ли там хуже. (Не проверял.)

Но как и я говорил, если кому охота, то почему бы и нет.

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

Фактически на сервере выполняется gas бинарник.

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

У php есть проблема для применения в качестве языка десктопных приложений – он сам создан и существует как «приложение» в определённой нише, а не как универсальный ЯП для произвольных задач.

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

Жутко неудобные костыли. Код с ними выглядит неопрятно.

Опять ты используешь какие то абстрактные слова, что значит костыли? Эти функции предлагает только PHP, больше не существует языка со столь удобной структурой данных.

А так взять тот же Ruby – там намного удобнее работа с массивами и любыми итерируемыми сущностями.

Там отсутствует массив из PHP, со всеми его преимуществами.

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

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

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

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

Эти функции предлагает только PHP, больше не существует языка со столь удобной структурой данных.

Там отсутствует массив из PHP, со всеми его преимуществами.

Ты забыл описать, в чем проявляются эти удобство и преимущества.

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

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

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

Ты забыл описать, в чем проявляются эти удобство и преимущества.

PHP массив объединяет в себе массив, карту, множество, и даже хеш реализовано более правильно сохраняя порядок вставки, рандомная функция которая работает с массивом, может работать и с хешем и с множеством потому что это одно и тоже. То как производится работа с элементами тоже очень важно, array_filter и другие всегда сохраняют ключ элемента, что приводит к лаконичному коду если этим преимуществом пользоваться, функции стандартной библиотеки такие как str_replace принимают не только строку но и массивы что бы можно было проводить массовые операции без использования циклов или вызова map.

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

PHP массив объединяет в себе массив, карту, множество, и даже хеш реализовано более правильно сохраняя порядок вставки, рандомная функция которая работает с массивом, может работать и с хешем и с множеством потому что это одно и тоже.

Звучит всё это красиво, а на практие даже не вспомню, когда мне последний раз пригождалась хэш-мапа, сохраняющая порядок вставки.

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

функции стандартной библиотеки такие как str_replace принимают не только строку но и массивы что бы можно было проводить массовые операции без использования циклов или вызова map.

Ну сомнительный бонус конечно - ну есть и есть. На практике намного чаще нужна preg_replace_callback.

Если уж так охота, можно для массивов метод gsub! в Руби доопределить в 4 строки кода.

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

Звучит всё это красиво, а на практие даже не вспомню, когда мне последний раз пригождалась хэш-мапа, сохраняющая порядок вставки.

Я тоже никогда о чем то подобном не задумывался, до того как начал обильно использовать array_*.

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

Конечно принципиально, я поэтому сделал вставку о array_filter, в Ruby так filter не будет работать. Нужно будет переопределять функции, об этом ниже.

Ну сомнительный бонус конечно - ну есть и есть. На практике намного чаще нужна preg_replace_callback.

Она тоже принимает массивы.

Если уж так охота, можно для массивов метод gsub! в Руби доопределить в 4 строки кода.

Да можно и на COBOL реализовать S-Exp. Все же я говорю не о возможности что либо сделать, я говорю о том что есть, чем пронизан язык, его стандартная библиотека и проекты.

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

Абстрактный интерфейс для перечисляемых сущностей в PHP уже завезли?

У тебя есть функция, которая обрабатывает массив при помощи вот этих array_filter и прочих. А теперь вместо array передаём туда объект, который порождает значения динамически. Будет работать?

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

Абстрактный интерфейс для перечисляемых сущностей в PHP уже завезли?

Ну уж лет 10 как завезли наверное, я на старых версиях не писал.

У тебя есть функция, которая обрабатывает массив при помощи вот этих array_filter и прочих. А теперь вместо array передаём туда объект, который порождает значения динамически. Будет работать?

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 3)
Ответ на: комментарий от wandrien

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

MOPKOBKA ★★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 6)
Ответ на: комментарий от enep

Что сразу не Basic?

Неудобен.

А если серьезно, то почему не C/C++, Pascal, Rust, то есть нормальные компилируемые языки, негоже что бы DE тормозил.

Ну, во-первых DE тормозит не из-за языка, это миф. Оно тормозит из-за черезжопных алгоритмов, из-за попыток впихнуть невпихуемое, просто из-за того что нет оптимизации.

На примере файлового менеджера.

Есть например 10000 файлов в каталоге. У каждого есть несколько параметров: имя, размер, дата создания. Реализация вывода этой информации на экран - на любом ЯП одинакова: запросил список файлов в цикл, пробежался по каждому, выполнил stat или его аналог, вывел. Производительность этой операции упирается в скорость ФС и системного вызова. Если суммарное время всех stat например 1000 мс - то они будут тысячей мс и на пыхе, и на джаве, и на С.

А вот оптимизация алгоритма вывода может быть разной от реализации к реализации.

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

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

Но скорость этой операции по-прежнему не будет зависеть от ЯП. От ЯП будет зависеть лишь количество написанного кода и потраченных нервов.

А вот PHP не для этого был создан. Изначально он был препроцессором HTML

Любой ЯП создается для программирования. В моем случае я его использую как Vala - обертку над низкоуровневым С-кодом.

PHP же дает наиболее удобную и безгеморройную работу с переменными, строками и массивами - это самая главная часть любого ГУЯ.

Вот например участок кода, отвечающий за обрезку длинного имени

if ((mb_strlen($display_name)>20)and($conf['truncate_file_names']=='1')) {
	$first16 = mb_substr($display_name, 0, 16);
	$last3 = mb_substr($display_name, -3);
	$display_name = "$first16...$last3";
}

Если параметр в конфиге равен 1 и длина имени больше 20, тогда берем первые 16 символов, добавляем к ним три точки и соединяем с последними 3 символами.

Сколько это займет на условном С? А главное чем такой код на С будет лучше этого кода на PHP? Выполнится на 20 мкс быстрее?

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

Судя по репам там все удалено

Не, в репы я еще это все не выкладывал. Но обязательно выложу.

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

В C нет списков, векторов и так далее, тут корректней будет сравнивать с C++ и STL

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

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

Или добавление элементов в отсортированную коллекцию.

Или рассчёт ключа для правильной натуральной сортировки.

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

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

https://github.com/sde-gui/libsmfm-gtk/blob/49ea8045018b2c843391dc7d86a72e17d9927497/src/gtk/exo/exo-icon-view.c#L3852

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

https://github.com/sde-gui/libsmfm-gtk/blob/49ea8045018b2c843391dc7d86a72e17d9927497/src/gtk/fm-cell-renderer-text.c#L39

А вот здесь структуры LayoutCacheKey, LayoutCacheValue тоже объявлены не просто так.

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

Да. И к сожалению на кастомной версии собранной с необходимыми модулями. Пых позволяет писать собственные модули на С\С++, после чего этот С-шный код может использоваться напрямую в PHP.

Ты серьезно??

xaTa ★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.