nixp.ru v3.0

3 ноября 2024,
воскресенье,
23:22:38 MSK

14 августа 2012, 03:00

PCManFM 1.0 — первый стабильный релиз файлового менеджера

5
Интерфейс PCManFM 1.0
Интерфейс PCManFM 1.0
Иллюстрация с сайта 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.

fb twitter vk
Дмитрий Шурупов

Автору: спасибо за прекрасно написанный текст новости! ;-)

LStranger

Спасибо за отзыв! :)

yesint

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

Eleidan

На вкус и цвет фломастеры разные :-)

На самом деле есть и приятные темы оформления. Не такие расфуфыренные, как у KDE или GNOME, но таки есть приятные ;-)

LStranger

Так большинство тем оформления вроде бы вообще не зависят от окружения, GNOME это, LXDE, XFCE или что ещё. Про KDE точно не скажу, впрочем.

rgo

Ой не туда вы смотрите… «Зри в корень», говаривал некий К. Прутков. Так вот здесь, корень явно прячется в папке «завантаження». Вряд ли он может прятаться где-то ещё, всё остальное не столь озадачивает, как эта женя за вантой. =)

Shaaarnir

Что Вы за бред пишите?

Специально для Вас пишу перевод с украинского на русский:

Заванта́ження — загрузка

LStranger

В данном конкретном случае — загрузки.

Но вообще-то гораздо полезнее иметь чувство юмора. :)

rgo
Shaaarnir

Что Вы за бред пишите?

Специально для Вас пишу перевод с украинского на русский:

Заванта́ження — загрузка

Шутка оказалась неудачной? Извиняйте. Я не хотел оскорбить ничьих чувств. С украинским я знаком лишь на уровне цементовоза, и пока не возникало необходимости это знакомство расширять. Но меня на самом деле озадачило это слово. Не то той степени, чтобы я полез в google.translate (кстати спасибо, за то, что вы сделали это за меня), но всё же озадачило.

rgo

> Не позднее релиза 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, даже она через два года выкинет мышку и будет работать с файлами с клавиатуры.

Eleidan

Сколько людей, столько и мнений. Философия GNOME (слизанная с яблочных ребят) довольно хорошая и проверенная временем и практикой. Больше всего мне в ней нравится «сделай так, чтобы было удобно и не приходилось бы ничего перестраивать». Меньше кода — меньше ошибок. Признаться, после минимализма GNOME-приложений у меня подчастую разрыв шаблона от прог писанных для KDE, — столько ненужных свистоперделок (их ещё и в настройках можно дрессировать!)…

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

Некоторые идеи довольно интересные, за что и «плюс» ;-)

rgo
Eleidan

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

Не приходилось участвовать в операции «дай человеку, который в жизнь компа не видел, комп»? Я участвовал. И не раз. И, хоть сам и не пробовал, но всё же уверен, что работу из терминала будет освоить проще. Во-первых меньше деталей рассеивающих внимание. Если глянуть на скриншот файлменагера в начале статьи, то там можно увидеть полсотни более-менее самостоятельных объектов, начиная с заголовка окна, продолжая пунктами меню, кучей каких-то слов слева, внизу какие-то надписи, справа какие-то картинки и надписи. Помимо этого скроллбары, тулбары, адресные строки… И это лишь в одном окошке, а ведь как правило окошко рисуется поверх десктопа, который добавляет ещё объектов, начиная с кнопки пуск, продолжая кнопками на таскбаре, но не заканычивая ими. Это хорошо и удобно, когда есть опыт, когда видишь только то, что нужно в данный момент, остальное же просто полетает мимо сознания незамеченным. Но для этого нужен опыт. Которого у рассматриваемого человека нет по-определению.

Во-вторых, команды в CLI выполняются последовательно и по-одной, и всегда ясно: выполнилась команда, или всё ещё выполняется. GUI требует кучи познаний, то что мы делаем автоматически и то, что считаем «интуитивно понятным», на самом деле навык, который ещё обресть надо. ПКМ, ЛКМ, и десяток различных способов скопировать файл. Это нисколько не помогает освоению интерфейса. В консоли же, есть ровно один способ скопировать файл: cp. У cp дофига опций, но человеку только начавшему осваивать консоль вовсе не обязательно даже подозревать о существовании этих опций. И вместо того, чтобы осваивать все эти понятия типа ЛКМ и пункт меню, человек может сконцентрироваться на конкретной задаче: скопировать файл.
Но не надо думать, что мысль о том, что bash проще для человека впервые севшего за комьпьютер — это моя собственная мысль, которую я сам взрастил и взлелеял. Не стоит так меня переоценивать. Изначально эту мысль мне в голову заронила некая success story, отчёт о которой я читал несколько лет тому назад. Там взяли группу таких людей, незнакомых с компьютером в ноль, и посадили их работать с cygwin. Сейчас, к сожалению, я не нашёл того отчёта. Но зато я нашёл вот это: www.osnews.com/story/6282 Там достаточно подробно объясняется и что такое человек, впервые оказавшийся за компьютером, и почему CLI интерфейс ему освоить проще чем GUI.

Eleidan

Признаться, после минимализма GNOME-приложений у меня подчастую разрыв шаблона от прог писанных для KDE, — столько ненужных свистоперделок (их ещё и в настройках можно дрессировать!)…

Это как вам угодно. Я в последний раз видел гном не на картинке (впрочем и кеды тоже) так давно, что уже даже не упомню когда это было. Если память мне не изменяет, на гном я задвинул где-то через полгода после того, как провернул в слаквари вручную обновление гнома из сорцов с версии 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

мне, например, очень удобно в таком, если много операций с файлами.

rgo

Но это же просто консоль, лишь слегка видоизменённая. Или я чего-то не так понял?

Илья Смирнов

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

LStranger

Это про какие идеи? Если про те, которые в статье, то они будут реализованы, сейчас ведётся подготовка. Если про те, что в комментариях, то они чересчур абстрактные, чтобы их реализовывать, да и интеграция с консолью — пользователи, которые переползают с винды, консоли боятся, так что для подавляющего большинства это останется невостребованным, а для остальных — они наверняка и так работают в консоли, а не в GUI FM.

Илья Смирнов

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

Илья Смирнов

Желаю удачи в реализации PCManFM, равно как и самой среды LXDE!

LStranger
rgo
Вот у меня всё руки не доходят до реализации моих собственных идей относительно файлового меганера, я уже лет пять жду, когда кто-нибудь догадается, что во всех этих графических файлменагера, катастрофически не хватает второй (или третьей/четвёртой/N+1) панели с терминалом, в котором запущен bash.

Добро пожаловать в Dolphin — там это есть и уже давно.

rgo
накладывать фильтры по имени файла чтобы отображались только те, что соответствуют шаблону, выделять файлы по шаблону (чтобы, допустим, потом можно было бы мышкой все эти выделенные файлы перетащить в уже запущенный gimp и открыть таким образом), чтобы командами можно было бы изменять вид отображения, порядок сортировки, просматривать файлы (как минимум текст и картинки), и естественно не все сразу в произвольном порядке, а те, которые подпадают под текущую маску (даже если она соответствует файлам в нескольких разных директориях), и в указанном порядке. А переименование/перемещение многих файлов согласно каким-то простым правилам? Согласно простым, но не тривиальным, то есть не просто все эти файлы, вон туда, не изменяя имени. Не, что-нибудь типа: взять из этой директории и всех её поддиректорий все картинки, и сложить в указанную директорию, переименовав все в lower-case. А потом взять оттуда же все htm файлы, сложить в другую директорию, и сменить им унылое DOS’овское расширение htm, на гордое полноценное html.

Достаточно заглянуть в исходники libfm, чтобы увидеть, что там имеется TODO по всем этим пунктам.

rgo

>  Добро пожаловать в 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, речей Столлмана, и пр… Но и тем не менее, я подчеркну фразу, с которой я начал: «но я, на самом деле, не очень верю в пакмана». На данный момент — это вопрос веры. А что будет дальше — посмотрим.

Дмитрий Шурупов
rgo

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

[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»

 

LStranger

:)