AppSet — GUI фронтенд для консольных пакетных менеджеров, в частности для pacman/alpm. Ещё не так давно он выглядел в расцветку оффсайта ArchLinux, что несомненно придавало ему шарм, но сейчас уже выглядит как и все qt-приложения... Один из немногих вменяемых графических пакетных менеджеров для арча.

Что же этот AppSet умеет?

• Автоматическая генерация пакетов по разделам (игры, офис, мультимедиа, интернет и т.д.)
• Встроенный браузер, показывающий домашние страницы пакетов
• Отображение новостей с сайта
• Иконка в трее, показывающая доступные обновления
• Очистка кэша пакетов
• При установленном packer позволяет работать с AUR (у меня, почему-то, не стал искать по aur — но особого желания ковырять не было)
• При запуске через appset-launch сам спрашивает пароль для sudo через kdesu или gksu (на крайнях xterm запускает, хотя просто через sudo никто)
• Ну и конечно стандартный набор возможностей: установка; удаление; обновление; поиск; отображение списка установленных, неустановленных или требующих обновления. И всё это с возможность (опционально) видеть вывод бэкенда, то бишь pacman/packer

PKGBUILD и оффсайт на котором ещё пару скринов.

PS. надеюсь он не отдаст концы как и многие другие графические пакетные менеджер... Хотя, используемый во многих дистрибутивах PackageKit (имеющий как консольный так и gtk и qt интерфейсы) поддерживает ArchLinux (здесь список поддерживаемого — для арчеводов интересен бекенд alpm) и постоянно развивается, и судя по всему забрасывать его никто не собирается, скорее наоборот...

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

Графический интерфейс и командную строку часто противопоставляют другу другу. Причем то, что поклонники GUI считают достоинствами, в глазах любителей CLI — недостаток. И наоборот. «GUI — самодокументированный интерфейс. — говорят первые, — Мне не нужно читать инструкцию, чтобы разобраться в грамотно спроектированном GUI, я просто смотрю на него, открываю меню, другое, третье, и через несколько минут (или секунд) делаю, что мне надо». «А как насчет десятого или сотого раза? — возражают вторые. — Всё это изобилие кнопочек и значков превращается в раздражающий визуальный шум и мешает работать. А скорость? Разве может сравниться хождение по многоуровневым менюшкам со стремительностью клавиатурных команд?» «Стремительность, говорите? — отвечают первые, — А изучать руководство на сотни страниц мелким шрифтом, чтобы выйти из вашего Vim-а, это тоже стремительно?»

Этот спор можно растянуть еще на несколько абзацев, но лучше подумать вот о чем: так ли уж необходимо терпеть недостатки каждого из интерфейсов? Нельзя ли быстро запрягать и так же быстро ехать? Ведь сторонники GUI на самом деле любят не кнопочки и разноцветные значки, они любят легкость обучения. Шедевры графического интерфейсостроения всегда легки и лаконичны, в них не встретишь буйства красок и россыпей кнопок. А любители командной строки привязаны не к монохромному аскетизму, а к скорости, ненавязчивости и предсказуемости консоли. Достаточно взглянуть на обилие цветовых схем подсветки синтаксиса того же Vim, чтобы убедиться в том, что суровые консольщики тоже любят, чтобы было красиво.

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

Недавно для своих нужд написал небольшой прокси-сервер, заменяющий содержимое ответа по заданному регулярному выражению. Интерфейс реализован на основе Tk, сам сервер построен на основе модуля HTTP::Proxy, так как в нем есть довольно удобная система фильтров. Замена может производиться как по статическим строкам, так и по полноценным регулярным выражениям. Если в регулярном выражении производится захват некоторого [...]

OpenDialog это по сути побочный код, возникший во время работы над проcмотрщиком графики zSea. Довольно большой кусок кода выдран из KFM и из него в свое время я сформировал компонент FileBrowser, который входит в состав библиотеки Box_Lib - в текущий момент компонент используется только для OpenDialog, но в недалеком будущем будет использован в новом, переписанном KFM.

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

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

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

В общем Колибри стала на шаг ближе к пользователям. :-)