PCManFM 1.0 — первый стабильный релиз файлового менеджера
5
Иллюстрация с сайта nixp.ru
Один из основных компонентов LXDE — легковесного рабочего окружения, базирующегося на графическом инструментарии GTK+, — файловый менеджер PCManFM — наконец-то обзавёлся первой стабильной версией (1.0). Релизу способствовало интенсивное исправление ошибок в приложении и доработка недостающих функций в последние месяцы.
Обновление версии получили оба компонента файлового менеджера: библиотека libfm, предоставляющая полный набор элементов и функций, необходимых для функционирования файлового менеджера, и собственно pcmanfm, который интегрирует элементы в приложение, осуществляет управление рабочим столом и предоставляет общее меню и сохранение настроек. Релиз объявлен стабильным, поскольку за последние полтора месяца с момента исправления последней критической проблемы ни одного сообщения о критической проблеме в баг-трекере не появилось
Самые заметные изменения (кроме исправления проблем) по сравнению с предыдущим (нестабильным) релизом:
- поддержка EXIF-миниатюр для отображения значков;
- поддержка внешних создателей миниатюр для форматов, не поддерживаемых «внутри»;
- оптимизация диалога изменения атрибутов файлов;
- поддержка стандартных клавиш-модификаторов для управления drag & drop;
- добавлена поддержка GNU Automake 1.12;
- добавлено создание ярлыков программ во всплывающем меню по правой кнопке мыши;
- добавлена возможность использовать собственные обои на каждом рабочем столе (такая возможность была раньше только в окружении KDE).
Работа над проектом продолжается: за время, пока релиз 1.0 находился в состоянии «кандидат в релиз», набралось много исправлений не критических замечаний и пожеланий. В частности, исправлена поддержка работы с несколькими мониторами, ускорена работа с каталогами, содержащими несколько десятков тысяч файлов. Выход следующего релиза — 1.0.1 — запланирован на сентябрь. Не позднее релиза 1.1 ожидается добавление двухпанельного режима, расширенная поддержка шаблонов и расширенный поиск файлов.
Постоянная ссылка к новости: http://www.nixp.ru/news/11877.html. Андрей Гриценко по материалам Blog.Lxde.Org.
PIXEL — новое легковесное рабочее окружение на базе LXDE для Raspbian Linux
1 4
Вышла легкая редакция Linux-дистрибутива ROSA Desktop Fresh R5 с LXDE
Вышел Linux-дистрибутив ROSA Desktop Fresh R4 на базе LXDE
2
Крупное обновление LXQt 0.8 станет доступным в ближайшее время 1
Файловый менеджер PCManFM-Qt объявлен готовым для использования
PCManFM 1.2.0 — следующий крупный релиз файлового менеджера 2
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Автору: спасибо за прекрасно написанный текст новости! ;-)
Спасибо за отзыв! :)
Хоспади, зачем же такой квадратно-гнездовой темой виджетов людей пугать :)
На вкус и цвет фломастеры разные :-)
На самом деле есть и приятные темы оформления. Не такие расфуфыренные, как у KDE или GNOME, но таки есть приятные ;-)
Так большинство тем оформления вроде бы вообще не зависят от окружения, GNOME это, LXDE, XFCE или что ещё. Про KDE точно не скажу, впрочем.
Ой не туда вы смотрите… «Зри в корень», говаривал некий К. Прутков. Так вот здесь, корень явно прячется в папке «завантаження». Вряд ли он может прятаться где-то ещё, всё остальное не столь озадачивает, как эта женя за вантой. =)
Что Вы за бред пишите?
Специально для Вас пишу перевод с украинского на русский:
Заванта́ження — загрузка
В данном конкретном случае — загрузки.
Но вообще-то гораздо полезнее иметь чувство юмора. :)
Шутка оказалась неудачной? Извиняйте. Я не хотел оскорбить ничьих чувств. С украинским я знаком лишь на уровне цементовоза, и пока не возникало необходимости это знакомство расширять. Но меня на самом деле озадачило это слово. Не то той степени, чтобы я полез в google.translate (кстати спасибо, за то, что вы сделали это за меня), но всё же озадачило.
> Не позднее релиза 1.1 ожидается добавление двухпанельного режима…
Та херня всё это. Очередная копия вендовосовского Explorer’а. Который в свою очередь родился как естественное развитие дурацких программ типа Norton Commander, которые своим унылым существованием пытались как-то сгладить убожество командной строки MS-DOS’а.
Вот у меня всё руки не доходят до реализации моих собственных идей относительно файлового меганера, я уже лет пять жду, когда кто-нибудь догадается, что во всех этих графических файлменагера, катастрофически не хватает второй (или третьей/четвёртой/N+1) панели с терминалом, в котором запущен bash. А лучше даже не bash в терминале, а bash работающий в адресном пространстве файлменагера и активно с ним взаимодействующий по любому поводу, чтобы вгоняя команды в терминал, можно было бы рулить всеми остальными панелями — типа накладывать фильтры по имени файла чтобы отображались только те, что соответствуют шаблону, выделять файлы по шаблону (чтобы, допустим, потом можно было бы мышкой все эти выделенные файлы перетащить в уже запущенный gimp и открыть таким образом), чтобы командами можно было бы изменять вид отображения, порядок сортировки, просматривать файлы (как минимум текст и картинки), и естественно не все сразу в произвольном порядке, а те, которые подпадают под текущую маску (даже если она соответствует файлам в нескольких разных директориях), и в указанном порядке. А переименование/перемещение многих файлов согласно каким-то простым правилам? Согласно простым, но не тривиальным, то есть не просто все эти файлы, вон туда, не изменяя имени. Не, что-нибудь типа: взять из этой директории и всех её поддиректорий все картинки, и сложить в указанную директорию, переименовав все в lower-case. А потом взять оттуда же все htm файлы, сложить в другую директорию, и сменить им унылое DOS’овское расширение htm, на гордое полноценное html.
Естественно на базе этого браузера, надо сделать ещё стандартный диалог открытия файла, чтобы наложив этот диалог в виде патча на gtk можно было бы иметь невероятно удобный диалог открытия файлов (естественно впихнув в этот диалог все возможности файлбраузера: в процессе поиска файла для открытия, иногда возникают сумасшедшие идеи о том, что можно сделать с файлами, допустим, что их стоит сначала заархивировать и лишь потом открывать…) Меня бесят существующие диалоги, в них крайне сложно добраться туда, куда надо. Хоть в них вроде и приделали автодополнение по TAB, чтобы можно было бы просто набрать имя файла как в командной строке, не продираясь через тысячи child’ов всех узлов перечисленных в пути файла, но дело в том, что этот долбаный TAB не всегда работает как ожидается, и вообще всё становится печально, когда я хочу открыть сразу много файлов: набрав маску файла для открытия, я никогда не могу проверить, что это именно та маска, которая мне нужна. Единственный способ проверить — это нажать кнопку Open, но если не угадаешь с маской, и под неё подпадают две тысячи файлов, то результат может быть печальным. А иногда маску-то я наберу, а файла такого и нету. Но выяснить это можно опять же, лишь нажав ентер. А если я хочу открыть десять файлов, каждый из которых в своей директории? В шелле я могу написать маску вида: ./*/my-file.txt, и иметь сразу все файлы, но все эти дизайнеры графических интерфейсов, как всегда вместо работы над функциональностью своего софта, слушают всяких там yesint’ов и думаю лишь о том, чтобы тему виджетов покрасивше нацепить. [...]
Короче, не буду углубляться в философию, просто подведу итог. Я высказал элементарнейшую идею, которая даёт огромные просторы для полёта фантазии. И этот полёт, если будет подкреплён вложенными человекочасами, может серьёзно расширить возможности графического файлбраузера, и в то же время, дать bash то, чего ему подчастую нехватает — удобного взаимодействия с чисто графическими утилитами. Идея тривиальна по своей сути, я не верю, что я такой уникальный, что она мне единственному пришла в голову. Я уверен, что каждый второй пользователь компьютера мечтает о командной строке в дополнение к tree-view дерева директорий и listview/tableview списка файлов. То есть идея не нова и всем известна. Но при этом мне совершенно непонятно, почему дизайнеры гуёв пинают болт, вместо того, чтобы работать. Почему я в XXI веке, в втором его десятилетии, до сих пор вынужден сидеть в bash для повседневной работы с файлами?
У меня есть лишь одно объяснение: все эти разработчики гуёв всячески подражают разработчикам GNOME, которые делают окружение для идиотов. И все они до ужаса боятся добавить в свои программулины что-нибудь такое, что не сможет понять 80-ти летняя маразматичная бабушка, которая от компьютера использует лишь монитор, и тот как осветительный прибор. Но мазафака, проводились же исследования и эксперименты, люди совершенно незнакомые с компьютером, легче и быстрее осваивают командную строку, нежели всё это засилье графических виджетов. А если эта командная строка при этом, будет лишь как дополнение ко всему остальному, и при этом, когда пользователь работает мышкой, она будет сама себе отдавать команды, соответствующие тем, что пользователь мышкой вытворяет, и выводить эти команды на экран, будто пользователь их ввёл, то даже обезьяна, которая не может прочитать не то что мануал к программе, но даже диалог About, даже она через два года выкинет мышку и будет работать с файлами с клавиатуры.
Сколько людей, столько и мнений. Философия GNOME (слизанная с яблочных ребят) довольно хорошая и проверенная временем и практикой. Больше всего мне в ней нравится «сделай так, чтобы было удобно и не приходилось бы ничего перестраивать». Меньше кода — меньше ошибок. Признаться, после минимализма GNOME-приложений у меня подчастую разрыв шаблона от прог писанных для KDE, — столько ненужных свистоперделок (их ещё и в настройках можно дрессировать!)…
Не соглашусь про идиотов: дай человеку файловый менеджер и терминал. Человеку, который в жизнь компа не видел. Вот не поверю, что в терминале ему понравится больше.
Некоторые идеи довольно интересные, за что и «плюс» ;-)
Не приходилось участвовать в операции «дай человеку, который в жизнь компа не видел, комп»? Я участвовал. И не раз. И, хоть сам и не пробовал, но всё же уверен, что работу из терминала будет освоить проще. Во-первых меньше деталей рассеивающих внимание. Если глянуть на скриншот файлменагера в начале статьи, то там можно увидеть полсотни более-менее самостоятельных объектов, начиная с заголовка окна, продолжая пунктами меню, кучей каких-то слов слева, внизу какие-то надписи, справа какие-то картинки и надписи. Помимо этого скроллбары, тулбары, адресные строки… И это лишь в одном окошке, а ведь как правило окошко рисуется поверх десктопа, который добавляет ещё объектов, начиная с кнопки пуск, продолжая кнопками на таскбаре, но не заканычивая ими. Это хорошо и удобно, когда есть опыт, когда видишь только то, что нужно в данный момент, остальное же просто полетает мимо сознания незамеченным. Но для этого нужен опыт. Которого у рассматриваемого человека нет по-определению.
Во-вторых, команды в CLI выполняются последовательно и по-одной, и всегда ясно: выполнилась команда, или всё ещё выполняется. GUI требует кучи познаний, то что мы делаем автоматически и то, что считаем «интуитивно понятным», на самом деле навык, который ещё обресть надо. ПКМ, ЛКМ, и десяток различных способов скопировать файл. Это нисколько не помогает освоению интерфейса. В консоли же, есть ровно один способ скопировать файл: cp. У cp дофига опций, но человеку только начавшему осваивать консоль вовсе не обязательно даже подозревать о существовании этих опций. И вместо того, чтобы осваивать все эти понятия типа ЛКМ и пункт меню, человек может сконцентрироваться на конкретной задаче: скопировать файл.
Но не надо думать, что мысль о том, что bash проще для человека впервые севшего за комьпьютер — это моя собственная мысль, которую я сам взрастил и взлелеял. Не стоит так меня переоценивать. Изначально эту мысль мне в голову заронила некая success story, отчёт о которой я читал несколько лет тому назад. Там взяли группу таких людей, незнакомых с компьютером в ноль, и посадили их работать с cygwin. Сейчас, к сожалению, я не нашёл того отчёта. Но зато я нашёл вот это: www.osnews.com/story/6282 Там достаточно подробно объясняется и что такое человек, впервые оказавшийся за компьютером, и почему CLI интерфейс ему освоить проще чем GUI.
Это как вам угодно. Я в последний раз видел гном не на картинке (впрочем и кеды тоже) так давно, что уже даже не упомню когда это было. Если память мне не изменяет, на гном я задвинул где-то через полгода после того, как провернул в слаквари вручную обновление гнома из сорцов с версии 2.4 на версию 2.6. И если я не ошибаюсь в номерах версий, то выходит (согласно википедии), что дело происходило в далёком 2004 году. На кеды я задвинул ещё раньше, поскольку, будучи написанными на C++, они собирались на Celeron’е 667MHz и 256Mb оперативки невероятно долго и нудно, а их огроменные значки в таскбаре занимали почти полностью нижнюю половину моего экрана 800×600.
Но давайте допустим, что я употребил там в тексте вместо слова «идиоты» какое-нибудь другое слово. Дело не в этом, а в том, что GUI файлбраузер как не мог заменить командную строку 20-30 лет назад, так не может и по сей день.
www.freesoftwaremagazine.com/articles/hotwire_a_combined_terminal_GUI_for_GNU_Linux
мне, например, очень удобно в таком, если много операций с файлами.
Но это же просто консоль, лишь слегка видоизменённая. Или я чего-то не так понял?
Если Вы реализуете перечисленные идеи в файловом менеджере, я буду его первым пользователем.
Это про какие идеи? Если про те, которые в статье, то они будут реализованы, сейчас ведётся подготовка. Если про те, что в комментариях, то они чересчур абстрактные, чтобы их реализовывать, да и интеграция с консолью — пользователи, которые переползают с винды, консоли боятся, так что для подавляющего большинства это останется невостребованным, а для остальных — они наверняка и так работают в консоли, а не в GUI FM.
Про те, что в комментариях. Было бы интересно увидеть в файловом менеджере интеграцию с консолью. Как пользователю, постоянно работающему и с консолью, и с графическим файловым менеджером, мне не хватает такой интеграции. При удачной реализации, позволяющей не отпугнуть пользователей, не привыкших к консоли, перечисленных в комментариях идей файловый менеджер многое бы выиграл.
Желаю удачи в реализации PCManFM, равно как и самой среды LXDE!
Добро пожаловать в Dolphin — там это есть и уже давно.
Достаточно заглянуть в исходники libfm, чтобы увидеть, что там имеется TODO по всем этим пунктам.
> Добро пожаловать в Dolphin — там это есть и уже давно.
Что такое Dolphin? Первая ссылка в гугле отправила мну на сайт посвящённый какой-то софтине под Android. Дальше не смотрел, испугавшись закрыл вкладку: она на джаве что-ли?
Да и просто bash в панели ничем не лучше, чем bash в отдельном окошке rxvt. В отдельном даже чем-то приятнее, поскольку можно всегда прибить файлбраузер, и продолжить работу с bash как ни в чём ни бывало.
> Достаточно заглянуть в исходники libfm, чтобы увидеть, что там имеется TODO по всем этим пунктам.
TODO это хорошо. Но хорошо недостаточно, поскольку совершенно не пригодно для повседневного использования. ;)
Но я, на самом деле, не очень верю в пакмана. Даже несмотря на TODO (я туда не заглядывал, но судя по тому что я наблюдаю в новости, и по ряду других признаков, скажем начало фазы оптимизаций по скорости, когда самые вкусные возможности существуют лишь в туду) я склонен считать, что он идёт не тем путём. Чтобы получить крутую софтину, надо писать не саму софтину, а фреймворк для написания софтины. В качестве примера, можно привести emacs: который, на самом деле просто lisp-система для обработки и отображения текстов. Но к нему прилагается /usr/portage/app-emacs/, где около двухсот пакетов. Можно привести другой пример: bash. Который на самом деле не файлменагер, а лишь фреймворк для работы с файлами. Но к нему прилагается /usr/portage/sys-apps/coreutils и куча других самостоятельных утилит.
Пакман же идёт классическим путём для мейнстрим разработчика: создать одну большую монолитную программулину. Возможно приделать к ней зубодробительный API для написания плугинов (такой API, чтобы любой нормальный человек, увидев его, в ужасе отшатнулся бы и продолжил бы использовать gitk, вместо написания git плугина к файлменагеру). Правда пакман не затачивается на третий пункт мейнстрим программы «грести деньги лопатой». Но первых двух пунктов достаточно, чтобы эволюционные возможности пакмана были бы ограничены тем, что уже существует и без него.
ps. Это лишь моё мнение. Мнение человека, который уже лет десять сидит в linux, и поковырял за это время немало программ, и до болезненной отрыжки учитался всякой идейной литературы типа TAOUP, речей Столлмана, и пр… Но и тем не менее, я подчеркну фразу, с которой я начал: «но я, на самом деле, не очень верю в пакмана». На данный момент — это вопрос веры. А что будет дальше — посмотрим.
Dolphin.
Заманчиво было бы посмотреть, но список депендансов убивает, многовато для просто «посмотреть». Даже рождается подозрение, что лучше он был бы на жабе: список, пожалуй, был бы короче.
[rgo tmp]$ USE=«qt3support -doc -handbook» emerge --pretend dolphin
These are the packages that would be merged, in order:
Calculating dependencies… done!
[ebuild N ] sys-apps/sdparm-1.07
[ebuild N ] sys-power/pm-quirks-20100619
[ebuild N ] dev-libs/libx86-1.1-r1
[ebuild N ] sys-libs/libutempter-1.1.5
[ebuild N ] virtual/eject-0
[ebuild N ] kde-base/kde-env-4.8.3 USE=«(-aqua)»
[ebuild N ] app-laptop/radeontool-1.5-r3
[ebuild R ] x11-libs/qt-core-4.8.2 USE=«qt3support*»
[ebuild R ] x11-libs/qt-gui-4.8.2 USE=«qt3support*»
[ebuild N ] x11-libs/qt-sql-4.8.2 USE=«exceptions qt3support sqlite (-aqua) (-c++0x) -debug -firebird -freetds -mysql -oci8 -odbc -pch -postgres (-qpa)»
[ebuild N ] x11-libs/qt-qt3support-4.8.2 USE=«accessibility exceptions (-aqua) (-c++0x) -debug -pch (-qpa)»
[ebuild N ] x11-libs/qt-xmlpatterns-4.8.2 USE="(-aqua) (-c++0x) -debug -pch (-qpa)»
[ebuild N ] app-crypt/qca-2.0.3 USE="(-aqua) -debug -doc -examples»
[ebuild N ] sys-apps/vbetool-1.1
[ebuild N ] sys-power/pm-utils-1.4.1-r2 USE=«alsa -debug -ntp» VIDEO_CARDS=«radeon -intel»
[ebuild N ] sys-apps/sg3_utils-1.33 USE=«-static-libs»
[ebuild N ] sys-apps/rescan-scsi-bus-1.29
[ebuild R ] sys-fs/udev-171-r6 USE=«gudev* hwdb*»
[ebuild N ] dev-libs/libatasmart-0.19 USE=«-static-libs»
[ebuild N ] sys-fs/lvm2-2.02.88 USE=«lvm1 readline static static-libs (-clvm) (-cman) (-selinux)»
[ebuild R ] x11-libs/qt-opengl-4.8.2 USE=«qt3support*»
[ebuild N ] x11-libs/qt-declarative-4.8.2 USE=«accessibility exceptions qt3support (-aqua) (-c++0x) -debug -pch (-qpa) -webkit»
[ebuild R ] dev-libs/libxml2-2.8.0_rc1 USE="-doc* -icu*»
[ebuild N ] x11-libs/qt-webkit-4.8.2 USE=«exceptions gstreamer jit (-aqua) -debug -icu -pch (-qpa)»
[ebuild N ] sys-block/parted-3.1 USE=«debug nls readline -device-mapper (-selinux) -static-libs -test»
[ebuild N ] gnome-base/gsettings-desktop-schemas-3.2.0-r1
[ebuild N ] sys-auth/polkit-0.104-r1 USE=«gtk introspection nls pam -debug -doc -examples -kde (-selinux) (-systemd)»
[ebuild N ] gnome-extra/polkit-gnome-0.105
[ebuild R ] sys-auth/consolekit-0.4.5_p20120320 USE=«policykit* -doc*»
[ebuild N ] sys-power/upower-0.9.16 USE=«introspection -debug -doc -ios»
[ebuild N ] sys-fs/udisks-1.0.4-r2 USE=«nls -debug -remote-access»
[ebuild N ] dev-util/automoc-0.9.88
[ebuild N ] kde-base/oxygen-icons-4.8.3 USE="(-aqua) -bindist»
[ebuild N ] media-libs/qimageblitz-0.0.6 USE=«3dnow mmx sse sse2 (-altivec) -debug»
[ebuild N ] dev-libs/libattica-0.4.0 USE=«-debug»
[ebuild N ] dev-libs/libdbusmenu-qt-0.8.2 USE="-debug -doc -test»
[ebuild N ] app-misc/strigi-0.7.7 USE=«dbus ffmpeg qt4 -clucene -debug -exif -fam -hyperestraier -inotify (-log) -test»
[ebuild N ] net-libs/libproxy-0.4.7 USE="-gnome -kde -mono -networkmanager -perl -python -test»
[ebuild N ] sys-auth/polkit-qt-0.103.0 USE="-debug -examples»
[ebuild N ] net-libs/glib-networking-2.30.2 USE=«gnome libproxy ssl»
[ebuild N ] net-libs/libsoup-2.36.1-r1 USE=«introspection ssl -debug -doc -samba -test»
[ebuild N ] media-plugins/gst-plugins-soup-0.10.30
[ebuild N ] media-libs/phonon-4.5.1-r1 USE=«gstreamer (-aqua) -debug -pulseaudio -vlc»
[ebuild N ] media-libs/phonon-gstreamer-4.5.0 USE=«alsa network -debug»
[ebuild N ] kde-base/kdelibs-4.8.3 USE=«3dnow acl alsa bzip2 mmx nls opengl policykit sse sse2 ssl udev udisks upower (-altivec) (-aqua) -debug -doc -fam -handbook -jpeg2k -kerberos -lzma -openexr -semantic-desktop -spell -test (-upnp) -zeroconf»
[ebuild N ] kde-base/katepart-4.8.3 USE="(-aqua) -debug -handbook»
[ebuild N ] sys-auth/polkit-kde-agent-0.99.0 USE="(-aqua) -debug» LINGUAS=«ru -ca -ca@valencia -cs -da -de -en_GB -eo -es -et -fi -fr -ga -gl -hr -hu -is -it -ja -km -lt -mai -ms -nb -nds -nl -pa -pt -pt_BR -ro -sk -sr -sr@ijekavian -sr@ijekavianlatin -sr@latin -sv -th -tr -uk -zh_TW»
[ebuild N ] kde-misc/polkit-kde-kcmodules-0.98_pre20101127 USE="(-aqua) -debug»
[ebuild N ] kde-base/libkonq-4.8.3 USE="(-aqua) -debug -test»
[ebuild N ] kde-base/kfind-4.8.3 USE="(-aqua) -debug -handbook»
[ebuild N ] kde-base/dolphin-4.8.3-r1 USE="(-aqua) -debug -handbook -semantic-desktop -thumbnail»
:)