MakeLinux — сделаем Linux лучше

Наблюдение о скорости прокрутки страниц в различных браузерах

2012-02-10T00:04:00.000-08:00

Случайно сегодня обнаружил, что в Midori содержимое страницы моргает, если при прокрутке над его окном расположено какое-либо другое окно. Выражается это в том, что те фрагменты страницы, которые, будучи закрыты другим окном, при прокрутке «выплывают на свет», сначала заливаются белым фоном, а уже затем с небольшой задержкой там появляется реальное содержимое. После этого я решил посмотреть, как обстоят дела с прокруткой в разных браузерах. И вот что выяснил:

Midori 0.4.3, xxxterm 1.10.0, luakit 2011.07.22. Все эти браузеры используют движок webkit, и во всех наблюдаются описанные выше артефакты. При этом, в Midori и xxxterm прокрутка (перетаскиванием ползунка на полосе прокрутки) ощутимо подтормаживает. (В luakit полоса прокрутки отсутствует, так что проверить не удалось.)

Opera 11.61. Тут наблюдается другой артефакт: страница обновляется по частям (соответствующим разбивке на прямоугольники от перекрытия другим окном), поэтому если прокручивать быстро, можно заметить моменты, когда в одной части страницы содержимое уже перерисовалось, в а другой — еще нет. Прокрутка, тем не менее, не тормозит.

Firefox 9.0.1, Chromium 16.0.912.77. В этих браузерах никаких артефактов нет, ничего при прокрутке не тормозит.

Dillo (r2362). Это минималистичный браузер, использующий собственный нетребовательный к ресурсам движок для рендеринга и тулкит FLTK для интерфейса. Выше я сказал, что в Firefox и Chromium тормозов нет. Так вот, только запустив данный браузер понимаешь: вот тут-то на самом деле нет никаких тормозов. В Firefox и Chromium же есть некая привычная и практически незаметная при использовании задержка в прокрутке страницы, которую начинаешь замечать только при наглядном сравнении с данным браузером.

Вопрос, который остаётся без ответа: почему же разработчики Chromium смогли задействовать webkit так, что перерисовка страницы в Chromium выполняется без тормозов, а разработчики Midori, xxxterm и luakit — не смогли?

Про костыли, C++ и OOC

2012-02-08T23:52:00.000-08:00

Тут недавно _winnie упоминал о неприспособленности C++ к решению простых высокоуровневых задач типа «разбить строку в список, отсортировать и отбросить повторяющиеся значения». По указанной ссылке мы видим некий несложный алгоритм, который должен выполняться максимально быстро, и потому написан на голом Си (то, что файл имеет суффикс cpp пусть не вводит нас в заблуждение). Плюс к этому, в программе имеется функция для парсинга аргументов, в которой возникла задача вида «разбить и отсортировать» — и вот тут-то автору и понадобился C++. Функция написана на страшной смеси Си и Си++ (кстати, а что, в STL не предусмотрен алгоритм split для строк? что за каменный век?) и занимает добрую экранную страницу, при том, что на Питоне аналогичный код, как правильно заметил _winnie, занимает одну строку.

То есть вся проблема заключается в совмещении низкоуровневого кода с высокоуровневым. Си++ тут, понятно, выступает совершенно лишней сущностью, т.к. по меркам по меркам 21-го века «Си с классами и шаблонами» на высоуровневый язык не тянет. Глядя на приведенную задачу, мы можем сформулировать какой же высокоуровневый инструмент нам нужен. Это должен быть язык, который:

Позволяет писать высокоуровневый код, по ёмкости не слишком отличающийся от Питона.
Статически типизирован.
Имеет грамотную стандартную библиотеку с контейнерами, строками, обобщенными алгоритмами и т.п. Оная библиоткета должна быть еще и по возможности компактной, чтобы не превращать одностраничный алгоритм в 2 мегабайта лапши после компиляции.
Из предыдущих 3-х пунктов очевидно, что необходима система автоматического вывода типов и генерики.
Позволяет с минимум костылей сочетать свой код с кодом на Си. Можно даже компилировать язык напрямую в Си и собирать далее на обычном gcc.

Какой язык соответствует этим требованиям? Всем сразу — вроде бы никакой. Во всяком случае, мне таковой не припоминается.

И теперь мы приходим к тому, о чем я, собственно, и хотел написать. Есть такой языс OOC, который разрабатывается уже года 3 и выглядит очень многообещающе. Сформулировав указанные выше требования, я вспомнил именно об этом языке, потому что он, потенциально, практически идеален по всем критериям (включая и компиляцию в Си). Я решил посмотреть, как обстоят дела у проекта, и насколько он способен прямо сейчас решить нашу задачу.

Давайте посмотрим, как потенциально мог бы выглядеть наш код на этом языке. Пусть у нас есть отдельный файл *.c, с основным алгоритмом программы, а процедуру парсинга мы организуем на OOC. Итак:

import structs/ArrayList
import text/StringTokenizer

cut_fields_fast: proto extern func(Pointer, Int) -> Int

main : func(args: ArrayList<String>) {
    if (args size() != 2) {
        stderr write("usage: cut field1,...,fieldN\nfields indices are sorted and uniqued.\n")
        exit(1)
    }

    columns := args[1] split(',') as Iterable<Int> toArrayList() sort() uniq()

    raw_array := columns toArray();
    return cut_fields_fast(raw_array, columns size)
}

Одна строчка кода, как и было запланировано. :-) Также обратите внимание на хорошую читаемость (читабельность?) кода и привычный всем нам, изнеженным Питонами и Руби, высокий уровень абстракций.

Но это — в теории. На практике же на данном этапе разработки дела обстоят не очень хорошо. Мы упираемся как в недоделанности компилятора, так и в отсутствие фич стандартной библиотеки. Прежде всего, для приведения Iterable<String> в Iterable<Int>, нам нужна хорошая, годная поддержка вывода типов. Написать кастующий итератор — не проблема:

IteratorCast: class<T1,T2> extends Iterator<T2> {
    real_iterator: Iterator<T1>
    caster: Func(T1) -> T2

    init: func (=real_iterato, =caster) {}

    hasNext: func -> Bool { real_iterator hasNext() }
    next: func -> T2      { caster(real_iterator next())}
    remove: func -> Bool  { real_iterator remove() }
}

IterableCast: class<T1,T2> extends Iterable<T2> {
    real_iterable: Iterable<T1>
    caster: Func(T1) -> T2

    init: func (=real_iterable, =caster) {}

    iterator: func -> Iterable<T2> { IteratorCast<T1,T2> new(real_iterable iterator(), caster) }
}

Но при попытке завернуть работу с итератором в обобщенную операцию приведения типа для контейнеров — вот такую:

operator as: func<T1,T2>(a: Iterable<T1>) -> Iterable<T2> {
    // ...
}

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

С sort() и uniq() нам тоже не повезло. В стандартной библиотеке их (еще) нет. Что печальнее, reduce() там нет тоже. Я попытался написать обобщенный reduce(), чтобы с его помощью сделать примитивные реализации sort() и uniq(), но наткнулся на те же ограничения в системе вывода типов. Увы-увы.

Итак, решив вообще не мучаться с сортировкой, а преобразование String в Int, сделав, так уж и быть, циклом, получаем следующее:

import structs/ArrayList
import text/StringTokenizer

cut_fields_fast: proto extern func(Pointer, Int) -> Int

main : func(args: ArrayList<String>) {
    if (args size() != 2) {
        stderr write("usage: cut field1,...,fieldN\nfields indices are sorted and uniqued.\n")
        exit(1)
    }

    columns := ArrayList<Int> new()
    for (i in args[1] split(',')) {
        columns add(i toInt())
    }

    raw_array := columns toArray();
    return cut_fields_fast(raw_array, columns size)
}

Ну тоже неплохо.

Также следует заметить, что в языке используется сборка мусора, основанная на анализе достижимости объектов. Конкретнее: библиотека Boehm GC. Но мы можем немного оптимизировать нашу программу, если откажемся от сборки мусора вообще. Я сейчас страшную для некоторых программистов вещь скажу, но это правда: в некоторых программах память можно не освобождать вообще. Ибо придёт неизбежный exit() и сам всё прибёрет. Вот наша программа как раз из этой категории. Так что можно просто заменить все обращения к Boehm GC на вызов malloc(). Язык позволяет делать такие выкрутасы — в теории. На практике же придётся вручную отредактировать один из файлов стандартной библиотеки, потому что соответствующий местный аналог ifdef там зачем-то закомментирован.

Всё это я тестировал на «релизной» версии, которая уже достаточно давно вышла. В версии из транка работа с типами (судя по документации) значительно улучшена. Мне просто лень её устанавливать, чтобы узнать подробности. В любом случае, язык к реальному использованию пока еще не готов, но выглядит очень многообещающе. На мой взгляд, это как раз тот язык, каким мог бы быть C++, если бы проектировался с умом. Собственно, цель поста заключалась в том, чтобы рассказать вам о существовании этого языка. Теперь вы в курсе.

PKGBUILD для io language, а также несколько слов о производительности Ruby, Python, Rebol

2012-02-06T01:10:00.000-08:00

Добавил в AUR PKGBUILD для языка Io. Возможно, кому-нибудь пригодится. (Если первый раз слышите про такой язык, то вам сюда.)

В составе исходных кодов пакета лежат скрипты для тестирования производительности базовых операций интепретатора (обращение к переменной, вызов метода, создание нового объекта и т.п.) для нескольких языков: Io, Ruby, Python и Rebol. Я решил ими воспользоваться, и вот что намерил:

Python 2, CPython

~/git/io$ python2 samples/speed/speed.py

Python localAccesses       := 33.54
Python localSets           := 29.58

Python slotAccesses        := 8.45
Python slotSets            := 7.29

Python blockActivations    := 2.99
Python instantiations      := 2.34
Python version := "2.7.2 final 0"

// values in millions per second

Python 3, CPython

~/git/io$ python samples/speed/speed.py

Python localAccesses       := 38.50
Python localSets           := 31.03

Python slotAccesses        := 7.78
Python slotSets            := 7.46

Python blockActivations    := 2.80
Python instantiations      := 3.41
Python version := "3.2.2 final 0"

// values in millions per second

Т.е. производительность 2-й и 3-й версии примерно одинакова. Повторный запуск тестов показывает устойчивый прирост скорости только на доступе к локальным переменным, остальные же значения примерно равны.

Ruby 1.8, MRI

Ну это известный тормоз, чему обычно очень рады питонисты, участвующие в форумных войнах Python vs Ruby. Измеряем:

~/git/io$ ruby-1.8 samples/speed/speed.rb

Ruby localAccesses       := 10.70
Ruby localSets           := 8.12

Ruby slotAccesses        := 5.85
Ruby slotSets            := 5.54

Ruby blockActivations    := 2.33
Ruby instantiations      := 1.83
Ruby version := "1.8.7"
// values in millions per second

Да, в самом деле тормоз. (Однако, см. примечание в конце поста.)

Ruby 1.9, MRI

А вот это уже интереснее.

~/git/io$ ruby samples/speed/speed.rb

Ruby localAccesses       := 63.57
Ruby localSets           := 38.74

Ruby slotAccesses        := 13.44
Ruby slotSets            := 27.92

Ruby blockActivations    := 8.63
Ruby instantiations      := 2.67
Ruby version := "1.9.3"
// values in millions per second

Итак, новая версия MRI наконец-то перестала быть тормозом и порвала CPython. Рубисты могут ликовать. Не долго, впрочем, ликовать, поскольку у Питона есть еще кое-что в запасе:

Python 2, pypy

~/git/io$ pypy samples/speed/speed.py

Python localAccesses       := 394.16
Python localSets           := 398.40

Python slotAccesses        := 150.94
Python slotSets            := 142.25

Python blockActivations    := 39.87
Python instantiations      := 119.99
Python version := "2.7.1 final 42"

// values in millions per second

Без комментариев. :-)

Rebol

Rebol localAccesses      := 31.1458560438534
Rebol localSets          := 15.208200261581


Rebol slotAccesses       := 31.6525812680024
Rebol slotSets           := 15.2397208083148


Rebol blockActivations   := 7.28682396490666
Rebol instantiations     := 0.0432321515089772


Rebol version := 2.7.8.4.2
// values in millions per second

Надо сказать, я об этом языке совершенно ничего не знаю, никогда на нём не писал ни строчки кода. Но раз уж лежит тест для него, установил интерпретатор и запустил. Довольно необычный результат: создание новых объектов невероятно медленное, остальные же показатели не хуже СPython.

Io

Ну и наконец виновник торжества, самый медленый:

~/git/io$ io samples/speed/speed.io 

Io localAccesses      := 6.23
Io localSets          := 2.86

Io slotAccesses       := 3.01
Io slotSets           := 1.43

Io blockActivations   := 0.16
Io instantiations     := 0.30
Io cfuncActivations   := 5.12
Io version := 20110905
// values in millions per second

Возможно, я его собрал как-то неправильно, но странно, почему он такой медленный. В принципе, сам по себе результат был бы не удивителен, т.к. над интерпретаторами Питона и Руби работает приличное количество людей, а Io, фактически, — проект одного человека. Однако в дереве иходников лежат старые результаты тестов, и если им верить, когда-то Io превосходил по скорости CPython, не говоря уж MRI:

Io localAccesses      := 26.73
Io localSets          := 10.32

Io slotAccesses       := 11.19
Io slotSets           := 4.89

Io blockActivations   := 3.66
Io instantiations     := 2.15
Io cfuncActivations   := 24.40
Io version := 20050615
// values in millions per second

Python localAccesses       := 23.23
Python localSets           := 23.25

Python slotAccesses        := 6.09
Python slotSets            := 5.89

Python blockActivations    := 1.59
Python instantiations      := 1.38
Python version := "2.3.0 final 0"

// values in millions per second


Ruby localAccesses       := 8.12
Ruby localSets           := 5.75

Ruby slotAccesses        := 3.36
Ruby slotSets            := 4.41

Ruby blockActivations    := 2.26
Ruby instantiations      := 1.44
Ruby version := "1.6.8"
// values in millions per second

Кроме того, по этим результатам, Io превосходит сам себя (т.е. мой тест) где в 6 раз, а где и вовсе в 22. Я полагаю, такую разницу невозможно объяснить различем производительности процессоров. Тесты я проводил в ОС Archlinux (32 бита) на системе с таким процессором:

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping : 2
cpu MHz  : 2612.191
cache size : 512 KB

У меня нет разумного объяснения, какое железо может дать тут прирост скорости однопоточной программы в 22 раза. Можно было бы списать на кэш-промахи, но крайне сомнительно, что тест blockActivations не уместился бы в кэш. Так что вопрос производительности Io требует дальнейшего изучения. Если найду время на это, постараюсь разобраться и отпишу о результатах.

Надо заметить, что из-за этого также и результаты тестов Ruby 1.8 под вопросом. Я собирал интерпретатор на своей системе, а не устанавливал готовый пакет.

Послесловие к посту о идеях из Windows

2012-02-02T03:06:00.000-08:00

На этот раз поговорим не о программном обеспечении, а о его несчастных пользователях. Я, разумеется, знал на что шел, публикуя подобный обзор. Но кто на citkit.ru и linux.org.ru бывал, тот флуда и троллей не боится.

К сожалению, 14 оставленных к посту комментариев не дают возможности провести развернутый анализ, однако кое-какие выводы сделать можно. Из 14-ти комментариев, только 2 относятся непосредственно к предмету статьи и вполне раскрывают мысль комментатора (а не просто «крикнул и убежал»). Еще несколько — ответы другим комментаторам. Прочие же представляю собой довольно любопытное явление. Т.к. всё равно цитирую их тут, то за одно и отвечу скопом на все. Итак:

Ты похоже просто никогда не видел KDE

Да разумеется не видел, вчера только с дерева слез, когда б я успел.

Он похоже просто никогда не вылазил из дефолтных ДЕ. Типичный мышкодав.

Если кто-то способен дешифровать это послание с планеты Шелезяка, черканите в комменты, что же он пытался сказать.

контрл ненужен ибо в кедах есть группы

А апельсины не нужны, потому что есть яблоки.

еще было бы круче назвать тему "M идей из Win 3.11, о которых..."

Если в Windows 3.11 есть хоть одна полезная идея, актуальная для современных DE, то об этом тоже стоит написать. Сарказм не удался.

у автора нет опыта работы на линуксе, или этот опыт болтается около нуля.

Опытная команда телепатов поставит любой диагноз через интернет.

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

Я ничуть не сомневаюсь, что в интернете достаточно много статей, не отличающихся не то что бы особой компетенцией, но вообще лишенных признаков оной. Однако этот комментарий показывает лишь неумение комментатора читать и ничего более. Поскольку если бы комментатор осилил прочитать статью, он бы выяснил, что попытки «объективно сравнить» не ставилось. А ставилась попытка найти те аспекты графической среды Windows, в которых она проработана лучше, чем DE для линукса (а для этого не требуется петь дифирамбы линуксу, и рассказывать, как здесь всё хорошо). Что и было сделано.

Ну и наконец, комментарий из категории «читать и плакать».

Крапают сейчас всякие статеек, типа ЭТОЙ, сравнилки, Windows восхвалялки и тут же усиленно Linux гнобилки... По на вытаскивают из подвалов истории несколько сомнительных достоинств имевшихся в Windows, раздуют их до уровня фишек первоочередной необходимости и начинают обвинять Linux"а в их отсутствии.
Заняться что ли нечем? Сколько бы недостатков не имели Linux системы, у них достоинств намного больше чем у Windows! Как бы не напрягались и не тужились, Windows безнадёжно отстал во всём! И не догонит уже, как бы дика не пиарили его и не вливались в него финансово. Катится оно пока по инерции... И дальше будет катится, как телега с горы! Не надо его всюду нахаливать, сами ехайте на ней, или скучно ехать?
Как бы мне не было в Linux"е, на Windows телегу я уже не пересяду! Хватит, накатался! Больше мне не хочется этой езды...

Что я могу сказать... Слова здесь бессильны, поможет только химия: корвалол, валерьянка, что там еще можно дать переволновавшемуся человеку.

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

Неспособность понимать прочитанный материал. Очевидно, что комментатор либо совсем не читал текст статьи, либо читал, но ничерта не понял. Невозможно представить, чтобы человек, не имеющий проблем с пониманием, нашел бы в моей статье «восхвалялки Windows», «гнобилки Linux», «раздувание сомнительных достоинств» и прочие плоды воображения автора комментария.
Неспособность аргументировать свою точку зрения. Как видно, никто даже и не пытался.
Стремление во всем видеть угрозу, а в людях — врагов. Вероятно, перед мысленным взором комментатора, когда он писал ко мне в блог, представала ужасная картина, как тёмные силы ловят его, удаляют с компьютера любимый линукс и заставляют пользоваться ненавистным Windows, угрожая в случае неподчинения страшными карами. Просто мания преследования какая-то.
Истеричность. И надо заметить, эта черта ничуть не удивительна на фоне предыдущей. Впрочем, сложно сказать: то ли истеричность порождает манию преследования, то ли мания преследования порождает истеричность.
Выяснение отношений вместо обсуждения по существу. Ну и наконец, закономерный итог: после того, как читатель неверно понял текст, не смог найти обоснований своего мнения, увидел для себя угрозу и начал истерику, остаётся наиболее простой выход: обвинить автора во всех грехах, назвать дураком или ламером, попытаться убедить себя, что перед нами на самом деле нечто недостойное внимания. Защитная реакция.

Обсуждения, касающиеся Линукса, здесь ничем не уникальны: всё то же самое вы найдёте в спорах о языках программирования, об автомобилях, о музыке, о сексе, о политике... — везде. Однако когда дело касается линукса, все эти черты приобретают столь острый характер, что можно говорить о форме религиозной фанатичности у большинства участников таких дискуссии. Чем еще, кроме как религиозной фанатичностью, можно объяснить то, что вполне невинная заметка на тему «а есть ли что хорошего в Windows, что можно было бы оттуда спереть» превратилась в глазах комментатора в воплощение зла, в страшную «Windows восхвалялку и Linux гнобилку», в «вытаскивание из подвалов истории сомнительных достоинств» и «обвинение Linux"а в их отсутствии», переходящее затем во «всюду нахаливание» и попытки «пересадить» читателя «на Windows телегу».
Чувак, ты просто задумайся: а с тобой всё в порядке? Помощь профильного специалиста не требуется?

N идей из Windows 98, о которых стоило бы знать разработчикам современных DE.

2012-01-26T08:32:00.000-08:00

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

Припомнив народную мудрость, что всё новое — это плотно забытое старое, в качестве ~~жертвы вивисектора~~ подопытной системы я установил Windows 98. Посмотрим, какие же идеи 14-ти летней давности актуальны для линукса и сейчас. Взяв быка за рога, переходим к первой и довольно неожиданной:

Тайлинг окон из контекстного меню панели задач.

Ух... да, вы всё прочитали правильно. В Windows 98 имеется поддержка тайлинга. Даже если вы об этом знали, то, готов спорить, уже наверняка забыли. Правда настоящим тайлингом это трудно назвать: панель задач умеет по команде из контекстного меню тайлить окна вертикально и горизонтально. Это всё.

Вы скажете: «Ну что за ерунда, тайлингом должен заниматься менеджер окон и делать это полноценно. WM в Windows этого не умеет.» Ну я на это скажу, что мой openbox тайлинга тоже не умеет, и в 99,9% процентах случаев мне этого и не нужно. Но если мне потребуется, раз в месяц, расположить несколько окон так, чтобы они не перекрывали друг друга, мне придётся сделать это вручную, а затем установить pytyle на случай, если это снова понадобится. Так что готовая команда, доступная в два клика, — это не лишне.

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

Что интересно, после выполнения действий Tile или Cascade, в меню появляется пункт для отмены этой операции, чтобы можно было «вернуть всё как было».

Однако сама по себе возможность затайлить все окна довольно бесполезна: обычно окон открыто много (особенно учитывая, что из коробки Windows не имеет поддержки переключения рабочих столов), и если ко всем применить тайлинг, на экране возникнет месиво из окон. И тут мы переходим к следующей особенности панели задач Windows:

Применение операций сразу к нескольким окнам панели задач.

Удерживая Ctrl, вы можете выделить несколько окон и затем из контекстного меню применить к ним действие:

Закрыть, свернуть, развернуть, затайлить, расположить каскадом — полный набор. Это достаточно очевидная и не трудная в реализации возможность, тем не менее, в распространёных панелях задач для линукса вы её вряд ли встретите. lxpanel так не умеет. xfce-panel так не умеет. gnome-panel из Gnome 2, скорее всего, тоже не умеет (сейчас мне не в чем проверить), т.к. работает на том же виджете, что и xfce-panel. Про всякие bmpanel и tint и вовсе говорить нечего.

В остальном панель задач Windows 98 банальна и никаких отровений не содержит. Однако стоит обратить внимание на такую возможность, не имеющую отношения к управлению окнами, как

toolbar-ы на панели задач.

Toolbar устроен удивительно юниксвейно: он просто отображает иконки файлов из заданного каталога. Помещение элементов в тулбар производится копированием файлов или созданием ярлыков в соответствующем каталоге. Щелчок по иконке выполняет умолчательное действие для файла: запуск бинарника, открытие документа и т.п.

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

У панелей для линукса мне встречались реализации виджетов навигации по структуре каталогов. Например, lxpanel имеет такой виджет. А вот виджет, отображающий содержимое каталога непосредственно на панели, — сходу не припомню, есть ли такие и для каких панелей.

Также нельзя не отметить, что такой тулбар мало чем (кроме внешнего вида) отличается от основного поля файлового менеджера: аналогичнм образом работает перетаскивание, в контекстном меню иконок доступно точно такое же меню файлов, как и в Проводнике. И это следующая полезная идея:

Универсальное меню файлов.

Файл — это ключевая абстракция в современном компьютере. Всё, что делает пользователь, крутится вокруг файлов. В файлах лежат данные пользователя. В файлах лежат программы. Всё есть файл. В начале было Слово, и Слово это было ф... так, постойте, нет, это уже из другой истории.

Ну так вот. Взаимодействие с компьютером при помощи командной строки подразумевает модель «действие — объект». (Т.е. «команда — файлы».) Работа в графическом окружении, наоборот, подразумевает модель «объект — действие». Сначала пользователь выбирает при помощи графического интерфейса объекты, затем выбирает действия, производимые с ними. Действия выбираются из меню. А это значит, что везде, где доступны некоторые объекты, должны, из соображений регулярности и предсказуемости пользовательского интерфейса, быть доступны и действия над ними. Везде — значит везде.

На уже упомянутом тулбаре:

В меню Пуск:

В утилите поиска файлов:

В стандартном диалоге открытия/сохранения. (Скриншот забыл сделать, так что верим мне на слово. :} )

Эта особенность Windows является одной из флудоносных тем на форумах, посвященных линуксу. Ведь в линуксовых DE, как вы знаете, нет ни универсального файлового меню, ни даже попыток его создать. (Ну если не знаете, то вот теперь узнали.) Вне зависимости от того, сколько раз форумные бойцы повторят «не нужно», «нефиг тащить дурные привычки» и «проводник — говно», с точки зрения принципов проектирования пользовательского интерфейса это по-прежнему крутая и нужная фича, повышающая предсказуемость UI и снижающая число лишних переключений фокуса внимания во многих use cases.

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

Ну и раз уж мы открыли утилиту поиска, то рассмотрим и её. Есть тут какие-нибудь полезные идеи?

Утилита поиска?

Ну на первый взгляд ничего особенного:

Критериев поиска не много, но и не мало. С универсальным языком запросов у find (1) это не сравнится, но для большинства типичных случаев вполне пригодно.

Кстати, а какие графические средства поиска (не являющиеся фронтэндами к демонам-индексаторам) вообще есть для линукс? Сразу вспоминается утилита gnome-search-tool. В принципе, она умеет и все те же критерии поиска, что виндовая утилита, и даже намного больше. Также есть catfish, который убог. Есть утилита в составе проекта EDE (который де факто мертв, поэтому она не считается). Наверняка есть и в KDE, но мне лень устанавливать что-либо KDE-шное, чтобы проверить.

У Xfce и LXDE подобных утилит нет. Так что для этих проектов наличие утилиты поиска файлов само по себе может являться идеей-которую-стоит-взять-на-вооружение. В самом деле, что же это за окружение графическое рабочего стола, если в нём нет штатного средства, чтобы ответить на вопрос «какие *.html файлы в каталоге проекта изменял Вася Пупкин вчера и позавчера»?

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

Сохранение условий и результатов поиска.

Итак, что делает действие Save Search. Оно сохраняет условия и результаты поиска (либо только условия, зависит от настроек программы) в файл на рабочем столе. Двойной щелчок по этому файлу откроет утилиту поиска точно в том виде, в каком она была в момент сохранения: с тем же текстом в полях ввода, с теми же строками в таблице результатов.

Выбора, куда сохранять, нет. Всегда сохраняет на рабочий стол. (В самом деле, вам вряд ли понадобится тусовать эти файлы-сейвы по каталогам.) Имя файла выбирается автоматически на основе условий поиска. (В самом деле, вы вряд ли захотите дать результатам иное имя, чем «Поиск по txt», если вы искали по *.txt.)

Я считаю это невероятно крутой вещью. Как по задумке (сама идея сохранять условия и результат), так и по реализации (два клика на сохранение, два клика на восстановление; ничего лишнего).

Следующая идея:

Справка на что угодно через контекстное меню.

Ну как бы всё очевидно — нажал правой кнопкой на практически любой элемент, получил краткую справку:

К сожалению, «что угодно» на самом деле совсем не что угодно. Во многих случаях контекстной справки нет, либо она довольно бестолкова. Тем не менее, на фоне тотального бардака в справочной системе наших DE, это просто сокровище. Ну я думаю, вы знаете: кто видел справку на приложения KDE, тот над шуткой «в Windows плохая справочная система» больше не смеётся. Фееричные руководства вида «А вот это меню Правка, а вот и список его пунктов» (скопипасченный прямо из исходников, вполне вероятно), которые писались не вполне трезвым Капитаном Очевидность. (Дабы поддержать баланс добра и зла, добавлю, что в Gnome ситуация со справочной системой принципиально не отличается.)

Ну а теперь вещь, ради проверки которой я и установилполез в Windows (еще до того, как мне пришла в голову идея этой статьи):

Непротиворечивое использовани мыши и клавиатуры в виджетах TreeView и ListView.

В приложениях, написанных на Gtk, с этими виджетами просто беда какая-то.

Вот возьмём типичное использование этих виджетов: отображение содержимого директорий. Тут имеют смысл два типа пометок обьектов: текущий и выделенный. Выделенные обьекты — это те, с которыми будут производиться любые операции. Текущий — это тот, который имеет пометку «вот тут находится клавиатурный курсор». В обычных условиях выделенный == текущий. Однако удерживая Ctrl или Shift, можно выделить произвольное число файлов (а курсор при этом может стоять на невыделенном файле).

Так вот. Если мы берём идею «операции производятся с выделенными объектами», то давайте следовать этой идее! В Gtk-шных же приложениях всё перепуталось. Если выделение находится одном файле, а курсор на другом, то Shift+F10 открывает меню для выделенного файла — верно. А вот enter выполняет действие над файлом под курсором, а не над выделенным — неверно! (Воспроизводится в: pcmanfm, thunar)

С мышью еще интереснее. Либо мы принимаем идею «левый клик выделяет, правый клик открывает меню для выделенных файлов» (так сделано, например, в PathFinder). Либо мы принимаем идею «выделять можно и левым, и правым кликом, но правый еще и открывает контекстное меню» (так сделано, например, в Проводнике). В pcmanfm решили сделать и не так, и не эдак. Левый клик выделяет объект. Если кликнуть по пустому пространству, выделение сбрасывается. Всё верно. Правый клик выделяет объект и открывает контекстное меню. Если сделать правый клик по пустому пространству, выделение не сбрасывается, и контекстное меню открывается не для вмещающего каталога, а для выделенных объектов. А вот это уже неверно!

В thunar, к слову, это работает правильно. В Проводнике — тоже:

Еще один вкусный баг: пункты боковой панели в файловых менеджерах. Этим пунктам приходится работать в трёх ипостасях: и как кнопка, по нажатию открывающая соответствующий каталог, и как объект, имеющий собственное меню и собственный набор действий, и как индикатор «сейчас открыт такой-то каталог». Всё бы ничего, но состояний у них всего два: выделен, либо не выделен. И поэтому фейлится либо роль обьекта с собственным меню (use case: щелкаем правой кнопкой, чтобы открыть меню; вместе с этим происходит активация кнопки, происходит переход в соответствующий каталог — fail). Либо роль индикатора (use case: щелкаем правой кнопкой, чтобы открыть меню; объект выделяется (это нужно, чтобы было видно, к какому обьекту открыто меню), но перехода в каталог не происходит — fail). Второй фейл, тем не менее, предпочтительнее первого, так что в thunar и pcmanfm реализован именно он.

Теперь, вместо отдельных пунктов, рассмотрим дерево каталогов в боковой панели. Суть та же, выделение означает 2 взаимоисключающие вещи: 1) этот каталог открыт; 2) к этому каталогу открыто контекстное меню. pcmanfm гордо не имеет поддержки контексного меню в дереве каталогов (то ли не планируется. то ли еще не реализовали), и этим решает проблему на корню. А вот thunar опять фейлится по тому же сценарию.

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

Вы можете подумать, что я зря потратил время, так подробно описывая эти небольшие (и не сказывающиеся на функциях программ) баги в интерфейсе. Однако пара этих багов — лишь частные случаи общей проблемы: графический интерфейс программ под линукс непредсказуем. Взаимодействовать с таким интерфейсом — всё равно что пользоваться отверткой с ручкой, которая впивается в руку, или носить неудобную обувь. Каждый раз, открывая даже стандартный с виду интерфейс, пользователь вынужден задать себе вопрос: что ожидать от него? Что делает левый клик, а что — правый? У каких объектов есть контекстное меню? Работает ли прокрутка как ожидается? Как программа реагирует на «стандартные» (даже в пределах тулкита) хоткеи? С какими вещами fd.o программа совместима? И так далее. Всё это делает работу с графическими приложениями в линукс несколько неприятной. GUI и так «не подарок», и для многих задач эффективнее использовать интерфейс командной оболочки. Однако есть задачи, которые всё же эффективно можно решить только в GUI. И вот тогда приходится сталкиваться со всеми этими проблемами.

Впрочем я уже далеко отклонился от изначальной темы статьи, и потому пора закругляться. Переходим к выводам:

Что делать?

Вы можете задаться вполне закономерным вопросом: ну написал автор всё это, и что дальше? Зачем он это писал? Кому это надо?

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

Во-первых, панель задач. Возможность выделить несколько окон при помощи Ctrl+щелчок я занесу в TODO-список для LXPanelX. Команды для тайлинга также могут быть полезны. Поскольку возможность добавлять в меню окон «внешние» команды запланирована на один из будущих релизов, то тайлинг вполне может выполняться внешней утилитой, а в самой панели достаточно только добавить команды в меню. Так что непосредственно панель задач никаким тайлингом заниматься не будет, но возможность для пользователя сделать такую вещь — будет.

Во-вторых, тулбары из каталогов. Такой апплет также запланирован для LXPanelX. (Вероятно, можно доработать апплет dirmenu для этого.)

В-третьих, графический фронтэнд для различных поисковых утилит и движков. Да, мы работаем над этим. :-D Анонс проекта сделаю позже, когда код перейдёт из категории «не тянет даже на препреальфу» в категорию «более-менее работает». Кто из вас бывает на LOR-е, возможно уже видели в одном из моих тредов в ссылку на репозиторий проекта.

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

На этом всё. Археологическую экспедицию можно считать оконченной.

P.S.
На прошлой неделе я обещал несколько статей о принципах устройства различных подсистем Linux. Я не забыл об этом, скоро первая будет опубликована.

Идеи и патчи

2012-01-25T11:24:00.000-08:00

В этом посте я буду собирать свои идеи по улучшению различного ПО и информацию о статусе этих идей: не реализовано, реализовано, патч принят в апстрим, патч отклонён и т.п.

Просмотрщики изображений + удаление в корзину

Я проверил 3 просмотрщика изображений (gpicview, viewnior, mirage) и обнаружил, что ни один из них не умеет удалять файлы в корзину.
Фактически, всё верно: незачем помещать в просмотрщик изображений функцию, которая относится к файловому менеджеру. Тем не менее, мимо корзины (unlink) удалять все они умеют. И раз уж на то пошло, есть замечательная юниксвейная утилита trash-put для помещения файлов в корзину. Осталось добавить юниксвейнойсти самим просмотрщикам.

Итак. Идея: добавить в просмотрщики изображений опцию вызова внешней команды для удаления изображений. Команду задавать в настройках. Либо можно просто использовать функции удаления в корзину из glib (вероятно, для разных просмотрщиков подойдут разные способы).

Статус: патчи отсутствуют, не приступал к реализации.

LXPanelX

2012-01-25T09:34:00.000-08:00

LXPanelX — универсальная NETWM-совместимая панель рабочего стола, не привязанная к конкретной графической среде (такой как Gnome или KDE), и написанная с использованием тулкита Gtk. LXPanelX является форком панели LXPanel, входящей в состав проекта LXDE. LXPanel, в свою очередь, ведет происхождение от fbpanel.

Основные характеристики LXPanelX:

Использование только библиотек, не завязанных на конкретное DE. LXPanelX зависит только от glib и gtk. Прочие зависимости опциональны: libmenucache (для меню приложений), asound (для регулятора звука).
Мощная и гибкая в настройке панель задач. Апплет панели задач является приоритетным направлением в разработке LXPanelX. В отличие от некоторых других панелей, таких как xfce-panel, панель задач LXPanelX не использует готовый виджет из библиотеки libwnck, а реализует все соответствующие функции (поддержку NETWM, отображение панели задач, управление окнами) самостоятельно. Это позволяет разработчику легко добавлять новые возможности, не дожидаясь их появления в сторонней библиотеке.
Возможность настройки без правки конфигурационных файлов текстовым редактором. Все настройки панели и апплетов (за несколькими исключениями, которые описаны в документации) доступны через настроечные диалоги.
Поддержка режима киоска (блокировка возможности изменения настроек) для использования на публично доступных компьютерах, в школах и т.п.
Легковесность aka нетребовательность к системным ресурсам. Нельзя сказать, что LXPanelX прямо таки совсем нетребовательна, однако она показывает хорошие результаты по сравнению с панелями из Gnome или KDE.

Релизы

В настоящее время ни одного стабильного релиза еще не выпущено. Следующий релиз будет иметь версию 0.6 (продолжает нумерацию релизов lxpanel, которая на момент форка имела версию 0.5.x). В настоящее время основные задачи для релиза выполнены, сейчас идёт доработка последних оставшихся задач и чистка багов. Следите за новостями.

Хотя со времени начала работ над проектом прошло более полугода, на сегодняшний день мы всё еще не готовы к релизу. Осознав порочность подхода "ползучего фичуризма", в дальшейшем мы будем следовать принципу release often.

Пакеты

Пакеты и установочные скрипты для различных дистрибутивов:

Archlinux
lxpanelx-svn в AUR.

Gentoo
lxpanelx-9999.ebuild в оверлее Megabaks-а.

Debian
Скрипты для сборки deb-пакета находятся в репозитории LXPanelX.

Agilia
Пакет lxpanelx входит в официальный репозиторий userland.

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

Дорожная карта

0.6

Основные задачи, запланированные на данный релиз:

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

0.7

Основные задачи, запланированные на данный релиз:
Ядро панели:

Реализация единого механизма для посылки апплетам произвольных команд извне.
Реализация автоскрытия панелей переносом реального окна панели за пределы экрана и использованием второго окна для "хвоста" скрытой панели. Эта реализация избавляет от ряда подводных камней, которые при "честном" скрытии виджета обойти проблематично либо невозможно.
Реализация показа/скрытия панели по команде.

Апплеты:

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

0.8

Основные задачи, запланированные на данный релиз:
Ядро панели:

Разделение кода Taskbar Plugin на model/view и перенос model в ядро.
Разделение кода Tray Plugin на model/view и перенос model в ядро.

Апплеты:

Tray Plugin: фильтрация иконок. После переноса основной логики в ядро, трей становится простым контейнером. Это даёт возможность размещать несколько апплетов трея и использовать фильтрацию иконок.
Реализация нового апплета Expander, обеспечивающего скрытие/показ соседних апплетов по клику мыши.

Скриншоты

[TODO: здесь будут размещены скриншоты]

Документация

[TODO: здесь будет размещена документация]

Ссылки

Репозиторий проекта на Google Code.

Анонс грядущих изменений на сайте

2012-01-14T22:58:00.000-08:00

Здравствуйте, дорогие читатели. Что-то подзабросил я блог, но вот решил вернуться.

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

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

Соответственно, все существующие посты блога сейчас я разделил на 3 категории: статьи, советы и ъ-ссылки. (За исключеним постов, посвященных lxpanelx, и еще нескольких заметок, которые не понятно, как классифицировать). Что касается проектов, то таковых сейчас у меня три: lxpanelx и два других, которые я анонсирую в скором времени. Т.к. навигация посредством ярлыков для проектов неудобна, для каждого будет создана отдельная страница-оглавление и страницы-подразделы.

Для повышения удобства, я добавил на блог оглавление — карту сайта. Карта генерируется при помощи JavaScript на основе ATOM-ленты блога. Если вы на странице карты ничего не видите, пишите мне об этом — буду чинить баги.

В обозримом будущем я планирую дописать и опубликовать несколько статей, посвященных устройству различных подсистем GNU/Linux. Я давно собирался заняться написанием этих материалов, но всё откладывал. Однако в последнее время я всё больше убеждаюсь, что идеологически GNU/Linux для современного пользователя представляет собой этакий «бесплатный Windows». Я имею ввиду не архитектуру, баги или методы работы с системой, а то восприятие операционной системы и её компонент, которое находится в голове пользователя. Отдельные подсистемы (да и вся система в целом) стали черными ящиками, в которые никто не заглядывает, и никто уже не помнит, что там внутри. Настройка системы и решение проблем производится магическим путём: «примени вот это заклинание с форума, а если не поможет, то поищи более мощное». Такое положение вещей меня в определенной мере печалит и сподвигло взяться за перо^Wклавиатуру. Не претендуя на попытки переделать людей, я рассчитываю лишь, что публикация моих материалов окажется полезной тем, кто желает понять, «как оно устроено на самом деле».

Как заставить xterm работать с xneur. Опция allowSendEvents.

2011-09-10T03:19:00.000-07:00

Как я упоминал ранее, при запущенном xneur, xterm совершенно не реагирует на ввод. Из-за этого приходилось добавлять его в список исключений. Но, как оказалось, xterm можно легко починить. Для этого необходимо включить в нём опцию allowSendEvents.

В уже запущенном xneur это можно сделать так: зажав Ctrl и нажав левую кнопку мыши, вызвать меню настроек и выбрать там пункт Allow SendEvents.

Чтобы xterm всегда запускался с данной опцией, нужно добавить её в файл ресурсов ~/.Xresources:

XTerm*VT100.allowSendEvents: true

(Файл ресурсов считывается только при логине в графический сеанс. Чтобы обновить ресурсы без релогина, выполните команду xrdb ~/.Xresources)

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

exec_first_of — скрипт для запуска первой найденной программы из списка

2011-09-07T06:52:00.000-07:00

Если вы используете один домашний каталог для работы на нескольких компьютерах и/или операционых системах, то довольно часто возникает потребность в различных системах использовать разный набор «умолчательных» программ. Например, при работе на машине A в качестве текстового редактора вы предпочитаете emacs, а при работе на машине B используете gedit, т.к. emacs там вовсе не установлен. Аналогично для эмуляторов терминала, браузеров, файловых менеджеров, просмотрщиков графики и т.п. Команды запуска этих программ могут фигурировать в самых различных конфигах и настройках. Как добиться того, чтобы без правки всех этих конфигов на разных операционных системах и компьютерах всегда выбиралась нужная программа?

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

#!/bin/bash

COMMAND="$1"
shift

if [[ "$COMMAND" = "--help" || "$COMMAND" = "-h" ]] ; then
    echo "exec_first_of searches first existing command in the PATH and runs it with the specified arguments."
    echo "Usage:"
    echo "       exec_first_of [options] commandlist [args...]"
    echo "       or"
    echo "       exec_first_of [options] -e varname [args...]"
    echo "where"
    echo "  commandlist    comma sepatared list of the commands"
    echo "  varname        name of the environment variable containing command list"
    echo "  args           arguments passed to the selected command"
    echo "options"
    echo "  -p             just print selected command, do not run"
    exit 0;
fi

PRINT=
if [[ "$COMMAND" = "-p" || "$COMMAND" = "--print" ]] ; then
    PRINT=1
    COMMAND="$1"
    shift
fi

if [[ "$COMMAND" = "-e" ]] ; then
    e='echo ${'"$1"'}'
    COMMAND="`eval $e`"
    shift
fi

IFS=':' read -a COMMANDS <<<"$COMMAND"

for c in "${COMMANDS[@]}" ; do
    read -a c <<<"$c"
    if which "${c[0]}" &> /dev/null ; then
        if [[ -z "$PRINT" ]] ; then
            exec -a "${c[0]}" "${c[@]}" "$@"
        else
            c=("${c[@]}" "$@")
            for p in "${c[@]}" ; do
                printf '%q ' "$p"
            done
            printf '\n'
            exit 0
        fi
    fi
done

echo "$0: no command found: ${COMMANDS[@]}" > /dev/stderr
exit 1

Скрипт выбирает из списка первую имеющуюся в системе команду и запускает её с указанными параметрами.

Первым аргументом скрипту указывается разделенный двоеточием список команд, среди которых будет осуществляться поиск:

exec_first_of medit:gedit # запускает medit, либо gedit
exec_first_of medit:gedit ~/somefile.txt # открывает в редакторе указанный файл

В списке команд можно указывать дополнительные аргументы запуска. Следующая команда выполнит lxterminal --geometry=150x55 -e mc, если в системе установлен lxterminal, либо xterm -fullscreen mc, если установлен xterm:

exec_first_of 'lxterminal --geometry=150x55 -e:xterm -fullscreen' mc

Если задана опция -e, exec_first_of будет читать список команд из указанной переменной окружения:

export GUI_TERMINAL='lxterminal --geometry=150x55 -e:xterm -fullscreen'
export GUI_EDITORS='adie:medit:gedit'

exec_first_of -e GUI_EDITORS ~/somefile.txt
exec_first_of -e GUI_TERMINAL mc

Помещаем файл со скриптом в один из каталогов, перечисленных в PATH (я использую ~/bin/ для самописных вспомогательных скриптов), назначаем ему права на исполнение. В ~/.profile вписываем переменные окружения с нужными нам списками команд. Например:

export GUI_TERMINALS='lxterminal -e:terminal:gnome-terminal:terminator:urxvt:xterm -fullscreen'
export GUI_EDITORS='medit:adie:gedit:kate:scite'
export GUI_FILEMANAGERS='pcmanfm:thunar:PathFinder:nautilus:worker'
export GUI_CALCULATORS='galculator:calculator'

Теперь везде, где требуется в конфиге указать, допустим, имя редактора, можно вместо имени конкретной программы указывать команду exec_first_of -e GUI_EDITORS, и она будет запускать первый доступный редактор из списка.

Например, в конфиге для xbindkeys:

"exec_first_of -e GUI_TERMINALS"
  Mod4 + q

"exec_first_of -e GUI_EDITORS"
  Mod4 + w

"exec_first_of -e GUI_FILEMANAGERS"
  Mod4 + e

"exec_first_of -e GUI_CALCULATORS"
  Mod4 + y

Также в ~/.bashrc можно назначить алиасы для оболочки:

alias _fm='exec_first_of -e GUI_FILEMANAGERS'
alias _ed='exec_first_of -e GUI_EDITORS'

Открытие URL в определённом профиле firefox

2011-07-22T13:30:00.000-07:00

Профили в Firefox — хорошая штука, но некоторые недоработки, связанные с ними, сильно мешают использовать их на полную катушку, а порой, откровенно бесят.

Например, опция командной строки -p используется, чтобы указать, какой профиль следует открыть — но работает эта опция только если ни одна копия Firefox еще не запущена. Если Firefox уже запущен, то эта опция игнорируется, и вместо открытия нового профиля, будет открыта вкладка в ужезапущенной копии. В итоге самое очевидное использование этой опции — открытие внешних ссылок в указанном профиле — оказывается неработоспособным.

Из-за невозможности запустить обычным способом параллельно два профиля, широко применяется опция -no-remote, которая заставляет Firefox не искать уже запущенные копии, а принудительно открывать указанный профиль. Отлично, запустить несколько профилей теперь удастся. Однако, эта опция бесполезна, если вы хотите открыть ссылку в уже запущенном профиле — т.к. запустить две копии программы с одним профилем невозможно.

Наконец, есть опция -remote, которая позволяет передать команду в уже запущенную копии приложения. Если вы используете вместе с ней опцию -p для указания профиля, то Firefox будет искать не первую попавшуюся запущенную копию, а копию, запущенную с заданным профилем. Казалось бы — вон оно, решение. Но и тут облом — если запущенный в этом режиме Firefox не находит ранее запущенной копии, он просто завершает работу. Так что и эта опция не поможет нормально работать с профилями.

Не знаю, как вам, а мне кажется, что всё это — редкостный идиотизм. Перерыв гугл на предмет "как запустить несколько профилей firefox", "firefox открыть ссылку в указанном профиле" и кучи других вариаций этого запроса на русском и английском, я нашел только множество обсуждений на форумах и ни одного ответа по существу. Реально куча народу каждый день наступает на эти грабли, и никто не может им помочь. В конечном итоге, мне это надоело, и я полез в исходники.

В общем, не буду долго тянуть кота за хвост: решение оказалось тривиальным. Настолько тривиальным, что я не понимаю, почему эту проблему не решили уже давно сами разработчики или кто-нибудь из пользователей не прислал патч. Firefox отлично умеет искать свои запущенные экземпляры, в том числе, и фильтруя их по нужному профилю, и умеет пересылать команды другому экземпляру. Весь код уже написан и работает. Давно написан. Прекрасно работает. Отсутствует же в нем самое тривиальное — при вызове программы как firefox -p profilename имя профиля не подставляется в параметры поиска запущенной копии.
Пять строчек кода. Пять чертовых строчек кода в файле toolkit/xre/nsAppRunner.cpp — именно столько надо дописать, чтобы исправить один из самых нелепых факапов в юзабилити файрфокса.

Вот этот элементарнейший патч:

diff -r 89b5fccb0514 toolkit/xre/nsAppRunner.cpp
--- a/toolkit/xre/nsAppRunner.cpp    Thu Jul 14 12:20:34 2011 -0400
+++ b/toolkit/xre/nsAppRunner.cpp    Sat Jul 23 03:14:32 2011 +0700
@@ -461,6 +461,8 @@
       if (strimatch(aArg, arg)) {
         if (aRemArg)
           RemoveArg(curarg);
+        else
+          ++curarg;
         if (!aParam) {
           ar = ARG_FOUND;
           break;
@@ -1408,10 +1410,17 @@
   nsresult rv;
   ArgResult ar;
 
+  const char *profile = 0;
   nsCAutoString program(gAppData->name);
   ToLowerCase(program);
   const char *username = getenv("LOGNAME");
 
+  ar = CheckArg("p", PR_FALSE, &profile, PR_FALSE);
+  if (ar == ARG_BAD) {
+    PR_fprintf(PR_STDERR, "Error: argument -p requires a profile name\n");
+    return REMOTE_ARG_BAD;
+  }
+
   const char *temp = nsnull;
   ar = CheckArg("a", PR_TRUE, &temp);
   if (ar == ARG_BAD) {
@@ -1434,7 +1443,7 @@
  
   nsXPIDLCString response;
   PRBool success = PR_FALSE;
-  rv = client.SendCommandLine(program.get(), username, nsnull,
+  rv = client.SendCommandLine(program.get(), username, profile,
                               gArgc, gArgv, aDesktopStartupID,
                               getter_Copies(response), &success);
   // did the command fail?

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

Картинко пропатченного файрфокса:

На скриншоте видно, как командами вида firefox -p porfilename запущены 2 профиля. Команды вида firefox -p porfilename http://somesite открывают ссылку http://somesite в уже запущенном профиле, и не путают профили между собой.

Очередная победа здравого смысла над разработчиками FF.

PKGBUILD для lxpanel globalmenu plugin

2011-07-15T13:48:00.000-07:00

Продолжаем танцы с бубнами. Сделал PKGBUILD-ы для библиотеки globalmenu (без лишних зависимостей от Gnome) и для плагина GlobalMenu для LXPanel.

PKGBUILD для библиотеки:

pkgname=globalmenu-core
_pkgname=gnome-globalmenu
pkgver=0.7.10
pkgrel=1
pkgdesc="GlobalMenu GTK plugin and server module"
url="http://code.google.com/p/gnome2-globalmenu/"
arch=('i686' 'x86_64')
license=('GPL2' 'GPL3')
depends=('gtk2')
makedepends=('vala>=0.6' 'libtool' 'pkgconfig' 'intltool' )
optdepends=()
options=('!libtool')
conflicts=('gtk2-aqd' 'gtk2-globalmenu' 'gnome-globalmenu-svn' 'gnome-globalmenu')
source=("http://gnome2-globalmenu.googlecode.com/files/${_pkgname}-${pkgver}.tar.bz2")
md5sums=('62d0ec181c7d7821f753591626b64d2f')

build() {
    cd ${srcdir}/${_pkgname}-${pkgver}
    export LDFLAGS=""
    export GMENU_CFLAGS=" "
    export GMENU_LIBS=" "
    ./configure --prefix=/usr --disable-tests --without-gnome-panel --without-xfce4-panel --disable-schemas-install \
       --sysconfdir=/etc --libexecdir=/usr/lib
    make || return 1
}

package(){
    cd ${srcdir}/${_pkgname}-${pkgver}
    make DESTDIR=${pkgdir} GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 install || return 1
    sed -i ${pkgdir}/usr/lib/pkgconfig/globalmenu-server.pc -e 's/ -lserver/ -lglobalmenu-server/'
}

Каждая строчка тут наполнена глубоким философским смыслом:

# Убеждаем ./configure, что вшитая намертво зависимость от libgnome-menu
# нам совсем-сосем не нужна.
export GMENU_CFLAGS=" "
export GMENU_LIBS=" "

# --without-gnome-panel — не ставить апплет для gnome-panel,
# --without-xfce4-panel — не ставить апплет для xfce-panel,
# --disable-schemas-install — не ставить апплет для gnome-panel, я сказал!
./configure --prefix=/usr --disable-tests \
   --without-gnome-panel --without-xfce4-panel --disable-schemas-install \
   --sysconfdir=/etc --libexecdir=/usr/lib

# И в третий раз повторяем: не ставить никакие куски gnome-panel.
# Впрочем, я без понятия зачем на самом деле это,
# но в исходном PKGBUILD оно было.
GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1

# Исправляем нелепую опечатку в pkgconfig.
# Без этого ничего не выйдет, всё пропало, шеф!
sed -i ${pkgdir}/usr/lib/pkgconfig/globalmenu-server.pc -e 's/ -lserver/ -lglobalmenu-server/'

Не смотря на тройную просьбу не ставить чертов апплет для gnome-panel, в пакете всё равно окажутся /etc/gconf/schemas/gnome-globalmenu.schemas и /usr/lib/gtk-2.0/modules/libglobalmenu-gnome-panel.so. При чём, зачем нужен второй файл, я даже приблизительно не представляю. Впрочем, они ничему не мешают.

Надо сказать, несмотря на концептуальную правильность архитектуры, организационно исходники globalmenu представляют собой ад и Израиль: есть клиентский модуль для GTK, есть серверный модуль, есть обертки для отображения серверного виджета на различных панелях... — вроде всё верно, но! Но какого черта всё это собирается общим лапшеобразным сборочным скриптом! ~~Убейте их кто-нибудь.~~ Сделайте и отправьте им патч кто-нибудь, вам это обязательно зачтётся в карму.

Одновременно заюзать эту сборку globalmenu и дефолтную сборку из AUR-а для gnome-panel — не выйдет. Впрочем, ну кто ж сейчас пользуется gnome-panel, когда есть это? ;)

И да — я изменил название пакета, убрав из него приставку «gnome-». Потому что к Gnome теперь он имеет такое же отношение, как апельсины — к свиньям.

Второй PKGBUILD на плагин для панели LXPanel, после предыдущего шокирующего ужаса, здесь всё просто:

pkgname=globalmenu-lxpanel-plugin
pkgver=0.0.1
pkgrel=1
pkgdesc="GlobalMenu GTK plugin and server module"
url="http://make-linux.blogspot.com/"
arch=('i686' 'x86_64')
license=('GPL2' 'GPL3')
depends=('gtk2' 'lxpanel' 'globalmenu-core')
makedepends=('gtk2' 'lxpanel' 'globalmenu-core' 'libtool' 'pkgconfig' 'intltool')
optdepends=()
source=("http://home.student.utwente.nl/j.vanderhoff/downloads/lxglobalmenu.tar.gz")
md5sums=('a002c9eb5f7aece0a2677dde56a2acdd')

build() {
    cd globalmenu
    ./autogen.sh
    ./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
    make || return 1
}

package(){
    cd globalmenu
    make DESTDIR=${pkgdir} install || return 1
}

Собирается плагин прямого из того самого архива, что валяется невозбранно на просторах интернета, и который никто не спешит доводить до ума. (В том числе, и я. Хотя собирался.) Так что когда полезут баги, помните, что я вас предупредил. На моей машине, тем не менее, оно работает.

Чтобы клиентская сторона globalmenu работала, не забудьте выставить переменную окружения для подключения модуля:

export GTK_MODULES=globalmenu-plugin

Чтобы отключить показ локального меню в окне, используте следующую команду:

globalmenu-settings show-local-menu false

Сборку этих билдов проверял в chroot-е со свежеустановленным Арчем — всё собирается и работает, значит, вроде ничего в зависимостях не забыл. И ничего лишнего тоже не тянет в систему, только мимально необходимое для сборки.

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

Модифицированная lxpanel (+ апплет globalmenu)

2011-06-08T05:28:00.000-07:00

Представляю вниманию посетителей блога форк панели LXPanel (которая входит в состав проекта LXDE). Форк носит условное название LXPanelX и разрабатывается вашим покорным слугой. Собственно суть проекта — доработка панели задач, входящей в состав LXPanel, до состояния, близкого к идеалу, каким я его вижу.

Список изменений:

Новые режимы.
Оригинальная LXPanel Taskbar имеет два режима отображения окон: классический и группировка окон одного приложения одну кнопку с выпадающим списком. Данный форк добавляет еще два: группировка окон одного приложения рядом на панели, но без слияния в одну кнопку, и режим отображения только кнопки для активного окна. В режиме отображения активного окна обычное поведение левой кнопки мыши (свернуть/восстановить) теряет смысл, поэтому щелчок левой кнопкой мыши открывает теперь контекстное меню окна (аналогично правому).

Улучшение режима группировки.
В режиме группировки, окна, относящиеся к одному приложению, группируются, только когда таких окон несколько. Если приложение имеет единственное окно, оно остаётся на панели "как есть", без группы. Такое поведение может вызывать неудобства в работе, т.к. не позволяет выработать автоматизм при взаимодействии с панелью: часть объектов панели при щелчке левой кнопкой мыши показывает выпадающее меню, а часть — выполняет переключение на другое окно. Чтобы улучшить ситуацию, была добавлена опция создания групп и для одиночных окон тоже: теперь любой объект панели задач ведет себя одинаковым, предсказуемым образом.

Возможность отключить отображение иконок окон.
В LXPanel Taskbar присутствовала возможность отображать иконки с заголовками или только иконки. Этот патч добавляет возможность отображать только заголовки, без иконок.

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

Доступ к контекстному меню настройки LXPanel.
Поскольку панель задач перехватывает щелчок ПКМ, вызывать её настройки было раньше достаточно неудобно: необходимо щелкнуть по любому другому апплету, который отображает контекстное меню панели по ПКМ, открыть общие настройки панели, а затем оттуда открыть настройки апплета панели задач. Сейчас контекстное меню LXPanel отображается при щелчке ПКМ по панели задач, если при этом удерживать клавишу CTRL.

Внутренние доработки в "ядре" панели.
В диалогах конфигурации апплетов добавлена возможность использовать выпадающие списки.
В API icon-grid добавлена функция для позиционирования одного элемента после другого.

Эти изменения можно считать нацеленными на повышение удобства работы на устройствах с малым разрешением экрана и/или на устройствах без мыши (с тачпадом или сенсорным экраном):

В режиме показа только активного окна контекстное меню окна доступно через щелчок ЛКМ по любому месту панели.
Также этот режим полезен, для экономии места на экране - панель задач можно использовать в качестве заголовка окна, а "настоящие" заголовки окон отключить в оконном менеджере.
Возможность отключения показа иконок тоже будет полезна для экономии экранного места.
Отображение кнопок закрытия позволяет закрыть любое окно в одно касание, даже если это окно перекрыто другими окнами, не имеет заголовка и т.п.

Сборка.
Исходники можно взять здесь.

PKGBUILD-ов и ebuild-ов, а также готовых пакетов пока нет. Вы можете взять *build для lxpanel из вашего дистрибутива и собрать при помощи него LXPanelX. (Используйте *build для версии 0.5.6 оригинальной панели.) Набор зависимостей и опции сборки полностью идентичны. Или можете пойти по пути наименьшего сопротивления, воспользовавшись ./configure && make && make install ;)

Для реализации некоторых изменений потребовалось внести правки в "ядро" панели и API плагинов, так что если вы попробуете скомпилировать апплет из файла taskbar.c с оригинальной панелью, у вас ничего не выйдет. Апплеты же для оригинальной LXPanel, наоборот, полностью совместимы с LXPanelX. (Правда таких апплетов, оформленных в виде отдельных от LXDE проектов, фактически, нет. Так что и терять совместимость на самом деле не с чем.)

Изменения в конфигах.
На уровне конфигов старый и новый вариант панели задач частично несовместимы, но работать будут (выдавая в stderr предупреждения о неизвестных опциях). В LXPanelX у панели задач удалены следующие опции: IconsOnly, GroupedTasks. А следующие добавлены:

Mode — число от 0 до 3, указывающее режим: classic, group side by side, group into button, single window.
ShowIconsTitles — число от 0 до 2, указывающее, что отображать на панели: иконки, заголовки, иконки вместе с заголовками.
ShowCloseButtons — булево значение, указывающее, отображать ли кнопки закрытия.
SelfGroupSingleWindow — булево значение, указывающее, создавать ли группы для одиночных окон.

Почему форк, а не патч в апстрим.
Согласен, что на полноценный форк это пока не тянет. Просто в один прекрасный момент у меня появилось целостное видение того, в каком направлении я хочу доработать панель задач, чтобы получить годный для себя вариант. Я сел за компьютер, реализовал идеи в коде и получил результат, который здесь и представлен. Если кто-то захочет послать патч в апстрим - хорошо. Если патч там примут - еще лучше. Но самому мне лень предпринимать какие-либо действия в этом направлении.
Я планирую дорабатывать панель и в дальнейшем, и, вполне вероятно, видение идеальной панели у меня и у разработчиков LXDE существенно расходится. К тому же, заниматься дурью типа миграции на GTK3 (а потом на GTK3.x, GTK3.y, GTK3.z...) мне не интересно, мне интересно получить работающий результат. Так что пока это условный форк, а потом видно будет.

Известные проблемы.

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

Использование совместно с gnome-globalmenu.
Некоторое время назад в списке рассылки LXDE промелькнула реализация апплета gnome-globalmenu для LXPanel.
Совместно с новыми возможностями панели задач, этот апплет будет особенно полезен для экономии места на экране.

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

Для сборки апплета необходимо установить LXPanelX (или оригинальную панель) и gnome-globalmenu. Если при сборке у вас появится ошибка отсутствия библиотеки server, создайте следующий симлинк: ln -s -T libglobalmenu-server.so /usr/lib/libserver.so — это баг в pkgconfig в gnome-globalmenu.

Скриншоты.
Панель задач в режиме группировки окон одного приложения рядом друг с другом:

Панель задач с отключенными иконками и включенными кнопками закрытия окон:

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

Ну и собственно, моя текущая настройка панели:

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

IRIX

2011-05-26T01:45:00.000-07:00

Тёплый ламповый IRIX.

Редактирование команд bash во внешнем редакторе

2011-05-14T02:38:00.000-07:00

В bash достаточно нажать (по умолчанию) Ctrl+X Ctrl+E, и текст из текущего буфера ввода будет открыт (через промежуточный временный файл) в редакторе, установленном в переменной окружения EDITOR. После выхода из редактора, текст из временного файла будет исполнен как команда оболочки.

Сводная таблица по bash из Advanced Bash-Scripting Guide

2011-05-10T02:34:00.000-07:00

Краткая, но информативная справка по bash из Advanced Bash-Scripting Guide.

Обзор графических просмотрщиков для GNU/Linux

2011-05-06T00:49:00.000-07:00

viewnior

Простой просмотрщик, отображающий указанные файлы или все файлы из каталога.
Реализован на библиотеке GtkImageView.

Возможности:

Просмотр свойств изображения.
Автоматическая ориентация по метаданным.
Поддержка анимации.
Просмотр на полный экран.
Слайдшоу.
Подгонка размера окна под размеры изображения.
Правка изображения: вращение, обрезка, отражение. Удаление файлов.
Drag'n'Drop файлов на просмотрщик и из него.
Установка изображения фоном рабочего стола (только для Gnome).
Меню «Открыть с помощью» для открытия файла в другом приложении. (На основе общесистемной привязки mime типов.)

eog (Eye of Gnome)

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

Входит в состав Gnome. Реализован на библиотеке GdkPixbuf.

Возможности:

Просмотр свойств изображения.
Автоматическая ориентация по метаданным.
Поддержка анимации.
Просмотр на полный экран.
Слайдшоу.
Правка изображения: вращение, отражение. Удаление файлов в корзину.
Drag'n'Drop файлов.
Установка изображения фоном рабочего стола (для Gnome).
Меню «Открыть с помощью». (На основе общесистемной привязки mime типов.)
Есть возможность переиспользовать уже открытое окно приложения вместо запуска второй копии.
Поддержка плагинов.

GPicView

Просмотрщик из проекта LXDE. Как пишут на официальном сайте, extremely lightweight and fast with low memory usage. Интерфейсно очень минималистичен: область просмотра и панель с кнопками под ней. Контекстное меню есть, но бесполезно, т.к. просто дублирует кнопки.

На роль «просто просмотщик без избыточной функциональности» годится лучше, чем viewnior и eog в силу двух вещей:
Во-первых, им удобнее управлять с клавиатуры, т.к. большинство действий по умолчанию привязаны к клавишам алфавитно-цифрового блока, а не сочетаниями модификатор+клавиша. Во-вторых, перетаскивание картинки при помощи левой кнопки мыши работает как прокрутка (в viewnior и eog это включает Drag'n'Drop).

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

Не привязан ни к какой DE. Зависит только от GTK.

Возможности:

Автоматическая ориентация по метаданным.
Поддержка анимации.
Просмотр на полный экран.
Правка изображения: вращение, отражение. Удаление файлов.

Ristretto

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

Пока еще крайне сырой. При попытке включить панель миниатюр, завис со 100% загрузкой CPU и при перезапусках развисать отказался.

Возможности:

Автоматическая ориентация по метаданным.
Поддержка анимации.
Просмотр на полный экран.
Слайдшоу.
Удаление файлов.
Меню «Открыть с помощью». (На основе общесистемной привязки mime типов.)

Mirage

Написан на питоне, использует GTK. (Соответственно, зависит от PyGTK.) Еще один «fast and simple» просмотрщик. Все они как один быстрые и простые, ага. На практике же запускается с ощутимой задержкой, а также чуть больше подлагивает на просмотре больших файлов, чем предыдущие просмотрщики.

Есть боковая панель с миниатюрами. В аргументах принимает как имена файлов, так и имена каталогов. Сначала я столкнулся со странным поведением: если передать два имени файла из разных каталогов, показывает список файлов из обоих каталогов и при листании, соответственно, пролистывает сначала все изображения из одного каталога, а затем из другого. Оказалось, чтобы просмотривать изображения точно по переданному в аргументах списку, надо выключить в настройках пункт Load all images in current directory — имейте ввиду, если будете пользоваться. Надо бы послать FR разработчику, чтобы эту настроку можно было указывать в прямо аргументах вызова, но мне лень.

Возможности:

Просмотр свойств изображения.
Поддержка анимации.
Просмотр на полный экран.
Слайдшоу.
Правка изображения: вращение, обрезка, отражение, изменение размера, изменение насыщенности. Удаление файлов. Переименование файлов.
Drag'n'Drop файлов отсутствует, вместо него перетаскивание мышью работает как прокрутка.
Можно задать свои наборы действий над файлами и назначить им горячие клавиши. В команду действия можно подставлять имя файла, полный путь и полный список файлов. В конце команды можно вписать флаги [PREV] или [NEXT] для навигации назад/вперёд после выполнения команды.
Можно сделать и сохранить скриншот.
Есть настройки качества масштабирования.
Можно рекурсивно загрузить в список все изобраежния в подкаталогах.

В целом, программа не произвела особого впечатления. Как быстрый и легкий просмотрщик он не годится из-за использования питона. Возможностей скриптования нет, хотя они прямо таки просят себя добавить, раз уж программа на питоне. Набор функций странен: тут и снятие скриншотов, и изменение насыщенности (зачем это просмотрщику?), но нет сортировки файлов.

Comix

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

Возможности:

Просмотр свойств изображения.
Просмотр на полный экран.
Слайдшоу.
Правка изображения: вращение, отражение.
Поддержка библиотек/коллекций.
Лупа. (Увеличенный фрагмент под указателем мыши.)
Перетаскивание картинки используется для прокрутки.
Возможность динамически подстраивать цвет фона на основании цветов по краям изображения.
Двухстраничный режим.
Отображение комментариев к изображению из текстовых файлов.
Подстройка яркости, контрастности, насыщенности, резкости при показе изображений. В том числе, автоподстройка контрастности.

Не поддерживает анимированные изображения.

feh

Это полностью юниксвейный просмотрщик изображений. Пользовательский интерфейс, фактически, отсутствует. Всё управление настройками и режимами работы осуществляется через аргументы командной строки. Идеален для использования из shell, для встраивания в различные скрипты и т.п.

Использует библиотеку Imlib2.

feh может работать в следующих режимах:

Slideshow. Просмотр указанного списка изображений. Изображения могут быть удалены (либо только из списка, либо с диска). Измененный список можно сохранить в файл.

Multiwindow. Показывает каждое изображение указанного списка в отдельном окне.

Montage. Склеивает несколько изображений вместе и показывает результат. Можно сохранить результат в файл.

Collage. Аналогично montage, но размещает изображения случайным образом.

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

Thumbnail. Показывает окно, аналогичное режиму index, но на миниатюрах можно кликнуть мышкой, что откроет просмотр изображения в новом окне.

List. Не показывает изображений, а просто выводит на stdout таблицу с параметрами изображений, подобно ls -l для файлов.

Некоторые возможности:

Большинство хоткеев по умолчанию удобно расположены в алфавитно-цифровом блоке клавиатуры. Впрочем, всё это легко настраивается в конфиге.
В файле конфигурации можно задать именованные наборы ключей командной строки и затем вызывать feh, указывая только имя набора.
Может использоваться для установки фона рабочего стола.
Можно задать до 10-ти команд, которые срабатывают при нажатии на Enter и клавиши 1..9.
При просмотре файлов по списку, есть возможность указать файл, с которого начинать просмотр.
Можно сортировать по: name, filename, width, height, pixels, size, format, а также просматривать в случайном порядке.
Рекурсивный поиск изображений в каталогах.
Умеет отображать не только файлы локальной ФС, но по URL. (через библиотеку libcurl)
При получении сигналов SIGUSR1 и SIGUSR2 переходит на следующее/предыдущее изображение. К сожалению, других возможностей удаленного управления просмотрщиком не предусмотрено, а они были бы очень кстати для встраивания его в файловый менеджер, например.

gqview

Это уже не минималистичный просмотрщик, а довольно мощный менеджер (органайзер) изображений. При этом, достаточно легковесный. Имеет довольно гибко настраиваемый интерфейс и удобные биндинги клавиш.

При попытке использовать его как просмотрщик заданного извне списка файлов, можно увидеть неожиданное поведение: прокрутка колесом мыши будет нормально листать переданные в аргументах вызова изображения, но на его панелях всё время будет отображаться только каталог от самого первого изображения. Чтобы это побороть, надо запускать с ключем -t (скрыть панели). Если хочется при этом видеть еще и миниатюры файлов, то добавить ключ -l (создать и показать коллекцию из переданного списка файлов), но в этом случае при закрытии программы, она будет жаловаться, что вы не сохранили коллекцию. В общем, на такую роль он годится слабо. Зато годится для много чего другого:

Просмотр свойств изображения.
Автоматическая ориентация по метаданным.
Автоматически обновляет картинку при изменении файла.
Просмотр на полный экран.
Слайдшоу.
Подгонка размера окна под размеры изображения.
Правка изображения: вращение, отражение. Удаление файлов.
Действия «Копировать в», «Переместить в». Переименование файлов. Создание каталогов.
Drag'n'Drop файлов.
Установка изображения фоном рабочего стола.
Вместо автоматического меню «Открыть с помощью», в gqview предусмотрена возможность в настройках добавить в меню нужные команды (например, запуск gimp), при чем сразу же и с хоткеями.
Панель навигации со строкой адреса, деревом каталогов и списком изображений в текущем каталоге.
Различные режимы сортировки списка.
Возможность отображать миниатюры в списке изображений.
Кэш миниатюр.
Назначение ключевых слов изображениям.
Коллекции (произвольные списки файлов).
Панель для просмотра данных EXIF.
Панель «менеджер сортировки» для удобного копирования/перемещения файлов в выбранный набор каталогов или коллекций.
Поиск изображений: по имени файла, размеру, дате модификации, размеру изображения, похожести на образец и ключевым словам.
Поиск дубликатов.
Множество тонких настроек интерфейса, возможность запоминания позиции окна и другие мелкие удобства.
Возможность печати изображения.
Возможность управления уже запущенной копией программы из командной строки.
Настройки качества масштабирования изображений.
Программа не теряет управляемость на загрузке файлов, загрузка может быть прервана.

Зависит только от GTK. Из недостатков: нет поддержки анимированных изображений.

Geeqie

Geeqie — это форк gqview, после того, как разработка последнего остановилась в 2006-м. Развивается с 2008-го года. Сохраняя все достоинства оригинала, приобрел много новых возможностей. Некоторые из них:

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

Выжимку change log-а проекта можно посмотреть вот здесь.

Версии программ, использовавшиеся при написании этого обзора:

$ pacman -Q viewnior eog gpicview ristretto mirage comix feh gqview geeqie 
viewnior 1.1-1
eog 2.32.1-1
gpicview 0.2.1-3
ristretto 0.0.93-1
mirage 0.9.5.2-1
comix 4.0.4-5
feh 1.13-1
gqview 2.0.4-3
geeqie 1.0-5

Зависимости и размеры пакетов:

$ env LANG=C pacman -Qi viewnior eog gpicview ristretto mirage comix feh gqview geeqie | egrep 'Name|Depends|Installed Size'
Name           : viewnior
Depends On     : gtk2>=2.12
Installed Size : 724.00 K
Name           : eog
Depends On     : gnome-desktop>=2.32.0  libexif>=0.6.19  lcms>=1.19  desktop-file-utils  gnome-icon-theme>=2.31.0  exempi>=2.1.1  python2>=2.7
Installed Size : 8052.00 K
Name           : gpicview
Depends On     : gtk2
Installed Size : 712.00 K
Name           : ristretto
Depends On     : libxfce4ui  libexif  desktop-file-utils  hicolor-icon-theme
Installed Size : 441.00 K
Name           : mirage
Depends On     : pygtk  desktop-file-utils
Installed Size : 664.00 K
Name           : comix
Depends On     : pygtk  pil  unrar  xdg-utils
Installed Size : 1564.00 K
Name           : feh
Depends On     : giblib  curl  libxinerama
Installed Size : 480.00 K
Name           : gqview
Depends On     : gtk2
Installed Size : 2796.00 K
Name           : geeqie
Depends On     : exiv2  gtk2  lcms  desktop-file-utils
Installed Size : 5204.00 K

dd с интерактивным показом хода копирования

2011-04-26T09:23:00.001-07:00

Утилита dd при получении сигнала USR1 выводит на stderr статистику хода копирования. Это позволяет написать скрипт, реализующий «интерактивный» аналог dd:

#!/bin/bash

# PID реального процесса dd
DD_PID=

# Обработчик события выхода из программы
exittrap()
{
    # Убиваем dd, если он запущен и еще не завершился
    [[ $DD_PID != '' ]] && ps $DD_PID > /dev/null && kill $DD_PID
}

trap "exittrap" EXIT

# Функция формирует интерактивный вывод
format_output()
{
    # unbuffer необходим для отключения буферизации потока, без него мы ничего
    # не увидим, либо увидим с большооооой задержкой.

    # Фильтруем строки с информаций о ходе работы dd
    # и пишем их поверх друг друга без перевода строк.
    unbuffer -p grep 'copied' --color=never | (
        spaces=
        while read line ; do
            echo -ne "\r$spaces\r$line"
            spaces=`echo -n "$line" | sed 's/./ /g'`
        done
    )
    echo
}

# Терминал, куда показываем интерактивный вывод.
# Внутри оператора >() команда tty не работает, поэтому запоминаем его здесь
TTY=`tty`

# Вызываем реальный dd, перенаправляем его stderr в наш обработчик
env LANG=C dd "$@" 2> >(
    format_output > $TTY
) &

DD_PID=$!

# Пока процесс dd жив, каждую секунду посылаем ему SIGUSR1,
# заставляя выдать статистику на stderr
while ps $DD_PID > /dev/null ; do
    kill -SIGUSR1 $DD_PID && sleep 1
done

Для работы скрипта необходима утилита unbuffer из пакета expect.

tail /dev/zero — заполнить всю доступную память

2011-04-24T09:21:00.000-07:00

При настройке параметров виртуальной памяти или лимитов процессов бывает необходимо, чтобы какой-нибудь процесс занял всю доступную память. Обычно первое решение, которое приходит на ум — выделение памяти в бесконечном цикле. Но проще всего это сделать командой tail /dev/zero.

Unix Toolbox

2011-04-22T07:06:00.000-07:00

Справочник/коллекция консольных команд GNU/Linux и FreeBSD «на все случаи жизни».

Тюнинг стилей gedit: делаем цвет подсветки скобок более адекватным

2011-04-17T09:30:00.000-07:00

Из пяти вариантов цветовых стилей, которые идут с gedit по умолчанию, сами приятными, на мой взгляд, являются Cobalt и Oblivion. К сожалению у этих стилей имеется мелкий, но достаточно неприятный недостаток: цвет подсветки парной скобки практически совпадает с цветом выделения текста. Когда курсор стоит на скобке, кажется, что выделение находится на соответствующей парной скобке, а когда выделен текст внутри скобок, кажется, что выделен текст + еще одна скобка.

Исправим это недоразумение. Копируем стиль cobalt из общесистемного в домашний каталог:

cp /usr/share/gtksourceview-2.0/styles/cobalt.xml ~/.local/share/gtksourceview-2.0/styles/cobalt1.xml

Открываем в текстовом редакторе и правим цвет фона для элемента bracket-match. Также изменим название и идентификатор стиля, чтобы не смешивать с оригинальным.

У себя я внёс такие изменения:

$ diff -u /usr/share/gtksourceview-2.0/styles/cobalt.xml ~/.local/share/gtksourceview-2.0/styles/cobalt1.xml
--- /usr/share/gtksourceview-2.0/styles/cobalt.xml    2010-09-29 00:53:06.000000000 +0800
+++ /media/work/home/vadim/.local/share/gtksourceview-2.0/styles/cobalt1.xml    2011-04-05 00:43:20.000000000 +0800
@@ -22,7 +22,7 @@
  Theme based on the style of the same name from pastie.caboo.se
 -->
 
-<style-scheme id="cobalt" _name="Cobalt" version="1.0">
+<style-scheme id="cobalt1" _name="Cobalt1" version="1.0">
   <author>Will Farrington</author>
   <_description>Blue based color scheme</_description>
 
@@ -47,6 +47,7 @@
   <color name="dark_red"                    value="#990000"/>
   <color name="bluish_grey"                 value="#777777"/>
   <color name="steelblue3"                  value="#4f94cd"/>
+  <color name="gr4"                         value="#444444"/>
 
   <!-- Global Settings -->
 
@@ -58,7 +59,7 @@
   <style name="draw-spaces"                 foreground="bluish_grey"/>
   
   <!-- Bracket Matching -->
-  <style name="bracket-match"               background="steelblue3"/>
+  <style name="bracket-match"               background="gr4"/>
   <style name="bracket-mismatch"            background="dark_red" bold="true"/>
   
   <!-- Search Matching -->

Для стиля Oblivion поступаем аналогично.

Отключить писк системного динамика

2011-04-14T09:00:00.000-07:00

По умолчанию мерзкий писк динамика с системном блоке сопровождает каждое «неверное движение» в bash и некоторых других приложениях. Отключить звуки системного динамика можно несколькими способами:

Установить длительность сигнала равной нулю:

setterm -blength 0

Отключить «писк» в файле конфигурации библиотеки Readline:

echo 'set bell-style none' >> ~/.inputrc

Отключить писк в утилите GNU screen:

echo vbell on >> ~/.screenrc

В zsh настройки писка задаются переменной окружения ZBEEP и опциями BEEP, HIST_BEEP и LIST_BEEP.

В tcsh:

set nobeep
set visiblebell

Отключить звуковую индикацию в Иксах:

xset b off

Выгрузить драйвер ядра, отвечающий за вывод звука на системный динамик и занести его в черный список:

modprobe -r pcspkr
echo "blacklist pcspkr" >> /etc/modprobe.d/blacklist

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

/bin/echo -e "\33[10;25]\33[11;10]"

Или так:

xset b 10 100 50

Настраиваем в gedit хоткеи для переключения вкладок (да и вообще любые хоткеи)

2011-04-14T04:55:00.000-07:00

Приложений, в которых мне постоянно приходится пользоваться вкладками, ровно три: эмулятор терминала, текстовый редактор (gedit) и браузер. В эмуляторе терминала переключение между вкладками у меня настроено на сочетания Alt-F1...Alt-F12 и на Alt-Влево, Alt-Вправо — т.е. так же, как привычно всем, кто работал с виртуальными консолями. Gedit же по умолчанию переключает вкладки через Alt-1...Alt-0 и пальцеломающее сочетание Ctrl-Alt-PgUp и Ctrl-Alt-PgDown — что приводило к тому, что я между этими вариантами путался.

Штатной возможности переназначить хоткеи у gedit нет, поэтому долгое время мне было лень его настраивать. Но сегодня здравый смысл взял вверх, и погуглив, я нашел плагин EditShortcuts, решающий именно эту задачу.

Плагин представляет собой простой скрипт на Питоне, не требущий сборки и установки. Просто распаковываем editshortcut/ и editshortcut.gedit-plugin из архива в ~/.gnome2/gedit/plugins и активируем плагин в списке подключаемых модулей редактора, после чего в меню Сервис появится пункт для вызова диалога настроек горячих клавиш.

Чтобы назначить хоткеи на конкретные вкладки, откройте нужное число вкладок (иначе нужные пункты для хоткеев не появятся), затем в диалоге Edit Sortcuts в раскрывающемся списке DocumentsListActions назначьте нужные хоткеи пунктам Tab_0, Tab_1 и так далее. (Даблклик по пункту, чтобы перейти к вводу хоткея.)

Хоткеи на листание вкладок вперед/назад аналогично назначаются пунктам DocumentsNextDocument и DocumentsPreviousDocument в списке GeditWindowActions.

Маска для dot-файлов.

2011-04-09T23:32:00.000-07:00

Правильная маска для захвата всех .*-файлов, кроме . и ..

$ echo .[^.]*

Для захвата только .*-каталогов:

$ echo .[^.]*/

«Читай код»

2011-04-08T09:10:00.000-07:00

[...] Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось – я понял, что цена всем моим знаниям, университетскому образованию, и опыту – ломаный грош. Меня поражал простой факт – я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен – я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности - я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации.

То есть, до меня начало доходить, что есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать. Оно перпендикулярно «дизайн-паттернам» и книгам по ОО проектированию. И оно, это нечто, у Тола есть, а у меня – нет. Если мои знания не могут мне помочь сделать такую систему – то много ли они стоят? Понимание и знание требуется для действия, ни для чего другого – это не китайская декоративная ваза.

С этого момента я начал внимательно наблюдать за Толом, изучать его решения и подход, и твердо решил разобраться, что же это такое за неуловимая штука, которой я не понимаю. То есть, я «записался в ученики», и Тол с удовольствием взял роль наставника. И за несколько лет Тол сделал меня инженером, показав мне на практике, что это такое, и за что я ему буду всегда благодарен. [...]