учебники, программирование, основы, введение в,

 

Графический интерфейс (X11)

Графический интерфейс в Linux
На протяжении предыдущих лекций Мефодию ни разу не потребовалось для выполнения своих задач покидать пределы текстового терминала. Что и понятно: в основном он занимался освоением самой системы Linux, а главные средства управления ею – командная строка и текстовый редактор. Тем не менее, для современного пользователя персональный (да и вообще любой) компьютер – это не в последнюю очередь устройство с широкими графическими возможностями, и часть задач, которые должен выполнять компьютер, – непосредственно графической природы, например, показ фильмов или создание изображений. Но такими специфическими задачами использование графического интерфейса не ограничивается.
Графические средства ввода-вывода позволяют организовать интерфейс, принципиально отличающийся от терминала – оконный. Сегодня любому пользователю компьютера знакома такая модель организации графического интерфейса: окна, меню, кнопки. Оконный интерфейс позволяет использовать пространство экрана гораздо более эффективно, чем обыкновенный текстовый терминал на виртуальной консоли: здесь одновременно можно открыть несколько окон, относящихся к разным задачам, и наблюдать за их работой одновременно. Собственно, в рамках окна может выполняться любая задача, в частности, текстовый терминал. При помощи оконного интерфейса пользователь Linux может следить за несколькими задачами на разных терминалах одновременно, а не по очереди.
Оконный интерфейс. Модель интерфейса, в которой пространством ресурсов является экран – прямоугольная область, в которой организуется ввод и вывод. Субъектами в оконном интерфейсе выступают задачи, вводящие и выводящие данные в рамках окна – области в рамках экрана.
Однако все задачи управления системой в Linux решаются посредством текстового терминала, да и очень многие задачи пользователя – как заметил Мефодий даже по своему небольшому опыту – тоже, поэтому никакой системной необходимости в графических средствах ввода-вывода в Linux нет. Графический интерфейс в Linux – это отдельная задача, наподобие системной службы или демона, поэтому в некоторых системах программное обеспечение для организации графического интерфейса может вовсе отсутствовать. Такая задача получает единоличный доступ к устройству графического вывода (видеокарта), а программам, использующим графические ресурсы, она предоставляет объектную модель графических примитивов (функции рисования линий, прямоугольников, отображения цвета и т. п.), наподобие того, как ядро предоставляет доступ к ресурсам жесткого диска в терминах объектной модели файловой системы. Поэтому весь комплекс программ для работы с графическими устройствами принято называть графической подсистемой.
Пользователю домашнего настольного компьютера графический интерфейс почти наверняка понадобится при каждом сеансе работы. Можно настроить систему таким образом, чтобы процесс начальной загрузки завершался запуском графической подсистемы, так что даже регистрация пользователей будет происходить уже в графическом режиме при помощи специальной программы – экранного диспетчера (см. лекцию 10). Экранный диспетчер опознать очень просто: он всегда отображает окно с приглашением к регистрации login: и password:, которое может быть оформлено и минималистично, и с барочной пышностью. После регистрации в экранном диспетчере пользователю предоставляется сразу и доступ к системе, и доступ к графической подсистеме.
Однако ни в одной из систем, в которых работает Мефодий, ему не случалось встречаться с экранном диспетчером, и всюду он регистрировался в системе и работал только в текстовом режиме на виртуальной консоли. Поскольку графическая подсистема – отдельная задача, авторизованный пользователь может запустить ее из командной строки в любой момент: для этого используется команда startx, которую Мефодий и исполнил.
В некоторое недоумение ввел Мефодия предложенный ему выбор из нескольких кнопок. Проконсультировавшись у Гуревича, он выяснил, что каждая из кнопок соответствует программе, по-своему организующей графический интерфейс, и что он может попробовать их все по очереди и выбрать ту, которая будет наиболее подходящей для его стиля работы. Не мудрствуя лукаво, Мефодий нажал на первую же кнопку, "KDE".
После некоторого ожидания на мониторе возникло все то, что Мефодий ожидал увидеть в графическом интерфейсе: иконки, панель с кнопками внизу экрана, меню. Однако если бы после запуска startx Мефодий выбрал другую кнопку вместо "KDE", графический интерфейс предстал бы перед ним совсем в другом виде и предоставлял бы несколько другие возможности и приемы работы. Далее в лекции объясняется устройство графической подсистемы в Linux. Из этого объяснения станет понятно, почему процесс запуска графического интерфейса оказался двухступенчатым и почему работа с графическим интерфейсом в Linux может быть организована по-разному.

X Window System
Обратите внимание на то, что все заглавные буквы "X" в этой лекции – латинские.
На свете существует множество графических устройств, управление которыми на низком уровне (вывод изображений и ввод данных, например, о перемещении мыши) – задача совсем не для пользователя, тем более что каждый вид устройства управляется по-своему. Заботы о вводе и выводе на низком уровне берет на себя графическая подсистема Linux – X Window System, предоставляя пользовательским программам возможность работать в терминах оконного интерфейса.
X Window System возникла все в той же UNIX, причем проект этот был настолько наукоемок и настолько полно охватывал тогдашнюю область задач, связанную с графикой, что никаких серьезных альтернатив ему так и не появилось.
X-сервер и X-клиенты. Протокол X11
X Window System использует традиционную оконную модель, в которой пространством ресурсов является экран. Экран – это прямоугольник, на котором отображаются команды графического вывода и организуется обратная связь с устройствами графического ввода. Пример обратной связи – указатель мыши. Сама мышь – довольно простое устройство ввода, способное передавать информацию о перемещении курсора и состоянии кнопок. Указатель же отображает мнение подсистемы об абсолютных координатах гипотетической "точки ввода".
В примере указатель мыши показывает расположение точки ввода (на кнопке "WindowMaker"). Если сейчас Мефодий нажмет на левую клавишу мыши, графическая подсистема зафиксирует это событие ввода и передаст его той задаче, которой принадлежит соответствующая кнопка. Именно задачи (а не сидящий за монитором пользователь) и являются субъектами для X Window System, и именно между ними разделяются графические ресурсы. Каждой задаче принадлежит одно или несколько окон, представленных некоторой (как правило, прямоугольной) частью экрана. Внутри окна выполняются графические операции (вывод) и именно окнам передается поток данных от устройств ввода. Какое окно получит события ввода – определяется с помощью синтетического понятия фокус: вводимые данные передаются от графической подсистемы только тому окну, которое "получило фокус"; по умолчанию это происходит, когда указатель мыши попадает в часть экрана, занимаемую этим окном.
В более сложном случае окна могут перекрываться, частично занимая один и тот же участок экрана. Если дополнительно постановить, что каждое из них лежит на своей глубине, то самое "верхнее" будет отображаться полностью, и ему будет доступен для вывода и получения фокуса весь заказанный прямоугольник. Следующее за верхним окно может быть им "загорожено", и тогда отображается только часть этого окна, которую видно "из-под" верхнего. Заметим, что выводить это окно можно в пределах всего заказанного прямоугольника, просто видно может быть не все, и управление фокусом будет происходить на основании видимой части окна.
Программа, которая отвечает за работу с устройствами графического ввода и вывода и обеспечивает при этом логику оконной системы, называется X-сервером (X Server, то есть сервер системы "Икс"). В рамках X Window System X-сервер – это ядро. Подобно ядру, он выполняет низкоуровневые операции и взаимодействует с аппаратурой, ничего самостоятельно не предпринимая. Подобно ядру, он предоставляет задачам унифицированный интерфейс к этим низкоуровневым функциям, а также занимается разделением доступа (окно и фокус) к графическим ресурсам. X-сервер не интересует, отчего эти задачи появляются и чем живут. Он только принимает запросы на выполнение графических действий и передает по назначению вводимые данные. Жизнеобеспечение процессов и даже способ передачи X-запросов – дело исключительно операционной системы, по отношению к которой и сам X-сервер – задача.
Задачи, которые обращаются к X-серверу с запросами, называются X-клиентами. Обычно X-клиент сначала регистрирует окно (можно несколько), которое и будет служить ему полем ввода-вывода. Потом он сможет рисовать в этом окне и обрабатывать происходящие с окном события: активность устройств ввода и изменение свойств самого окна (размер, перемещение, превращение в иконку, закрытие и т. п.). X-клиент в Linux – это процесс, запускаемый обычно в фоне (не связанный по вводу с терминальной линией). В самом деле, зачем процессу читать с терминала, когда для ввода он может использовать X-сервер? Если с X-сервером связаться не удастся, на стандартном выводе ошибок может появиться какое-нибудь сообщение – его легко перенаправить в файл.
X-сервер. Программа, принимающая и обрабатывающая X-запросы.
Клиент передает серверу X-запросы любым доступным ему способом. В разных версиях Linux, например, могут использоваться различные объекты файловой системы (чаще всего так называемые сокеты, сходные по функциональности с двунаправленными каналами). Во многих случаях запросы передаются по сети; при этом неважно, какой именно транспортный уровень будет использован для соединения клиента с сервером (в современных системах это, чаще всего, сеть TCP/IP и протокол TCP). Главное, чтобы клиент посылал стандартные запросы, соответствующие определенному протоколу обмена данными. Кстати сказать, другое имя X Window System – X11 (или X11R6) – это просто номер версии X-протокола, стандартизующего X-запросы, при этом "R6" обозначает номер подверсии (revision) и вполне может увеличиться, если X11R6 устареет настолько, что потребует пересмотра (revision).
"Голый" X-сервер, к которому не присоединен ни один X-клиент, можно запустить из командной строки – для этого достаточно выполнить команду "X" (одна заглавная латинская буква X). Именно так и поступил Мефодий — текстовая консоль сменилась черным экраном без всяких окон).
На экране есть только крест, который перемещается при перемещении мыши – курсор. Это означает, что X-сервер запущен корректно, установил необходимую связь с устройствами графического ввода и вывода и ожидает, когда к нему с X-запросами обратится какой-нибудь X-клиент. Однако, пока не запущен ни один X-клиент, для пользователя X-сервер совершенно бесполезен: кроме перемещения курсора сделать ничего невозможно. Мефодий мог бы растеряться, оказавшись перед черным экраном X-сервера, если бы не знал о том, что может переключиться обратно на любую виртуальную консоль, нажав сочетание клавиш Ctrl+Alt+FN, где N – номер консоли от 1 до 12. Переключиться обратно на экран, управляемый X-сервером, можно, нажав комбинацию клавиш Ctrl+Alt+F7.

DISPLAY
Чтобы начать работу с графической средой, X-клиенты должны каким-то образом доставить свой запрос X-серверу – для этого у X-сервера должен быть какой-то точный адрес. Адрес X-сервера, к которому должны обращаться с запросом X-клиенты, хранится в переменной окружения DISPLAY. Формат DISPLAY прост: способ_доступа:номер_сервера.номер_экрана. Под способом доступа может подразумеваться сеть (тогда используется сетевой адрес машины с X-сервером) или какой-нибудь другой механизм, принятый в конкретной системе. Если не написать ничего, будет выбран способ по умолчанию. Номер сервера нужен для различения разных X-серверов, запущенных на одном компьютере. В Linux можно запустить несколько X-серверов и переключаться между ними, как между виртуальными консолями – с помощью Ctrl+Alt+F7, Ctrl+Alt+F8 и т. д. В системе может быть несколько виртуальных серверов (см. раздел "Виртуальный сервер"). Все они должны иметь разные номера. Наконец, один сервер может работать с несколькими экранами – и физически (есть видеокарты с выходами на несколько мониторов), и виртуально (вот тут уж никаких ограничений нет). Правда, это бывает нечасто, и номер экрана тоже можно не указывать.
Адрес X-сервера, запущенного Мефодием, будет выглядеть так: ":0" – поскольку сервер запущен на той же машине, на которой работает Мефодий, можно использовать способ доступа по умолчанию (поэтому адрес начинается с двоеточия), поскольку сервер единственный, он получил номер "0", а экран можно не указывать. Теперь Мефодий может в любой командной оболочке (shell) указать адрес X-сервера в переменной DISPLAY, так что любой запущенный из этой shell X-клиент унаследует это значение и будет отправлять X-запросы тому серверу, который запустил Мефодий:
methody@susanin:~ $ export DISPLAY=:0
methody@susanin:~ $ echo $DISPLAY
:0
methody@susanin:~ $ xcalc &
В результате этих действий изменился экрана X-сервера: в левом верхнем углу открылось окно калькулятора – xcalc. Произошло следующее: при запуске xcalc проверил значение переменной DISPLAY и направил X-запрос по указанному там адресу; по запросу от X-клиента (xcalc) X-сервер выделил ему окно и выполнил необходимые операции графического вывода, чтобы отрисовать содержимое окна (опять же, по запросам xcalc). Теперь при помощи мыши и клавиатуры, переместив точку ввода на это окно, вполне можно что-нибудь вычислить, однако ни переместить окно, ни изменить его размер, ни свернуть – то есть выполнить те операции, к которым так привыкли пользователи оконного интерфейса, – невозможно: сам X-сервер их не производит. Для этих операций требуется специальная программа – диспетчер окон, о которой речь пойдет ниже.
С помощью специальных X-запросов можно изменить вид и поведение самого X-сервера из той же командной оболочки, в которой установлена переменная окружения DISPLAY. Например, команда "xsetroot-solid green &" изменит цвет фона на экране сервера на зеленый.
Итак, X-сервер запускается на одном компьютере, а X-клиенты вполне могут работать на других (причем на нескольких!), посылая ему запросы. С точки зрения человека, сидящего за (обратите внимание!) X-сервером, каждый такой клиент представлен в виде окна. Требования к аппаратуре на машинах, запускающих X-клиенты, будут изрядно отличаться от требований к аппаратуре машины для X-сервера. Типичная машина с X-сервером – это рабочее место (workstation). Она должна быть оборудована качественными устройствами ввода-вывода – монитором, видеокартой, клавиатурой и мышью. Что же касается ее вычислительных способностей, то их должно быть достаточно для выполнения X-запросов, и только. Такой компьютер не обязан работать под управлением Linux, на нем даже может вообще не быть операционной системы! В восьмидесятые годы выпускались подобные устройства, называемые "X-терминал" (X-terminal).
X-клиент. Программа, осуществляющая ввод и вывод графических данных при помощи X-запросов, обрабатываемых X-сервером.
В отличие от машины с X-сервером, компьютер для запуска X-клиентов может совсем не иметь устройств графического ввода-вывода. Его задача в том, чтобы все X-программы и запустившие их пользователи не мешали друг другу работать. На такой машине нужна хорошо настроенная операционная среда, с достаточным для запуска многих процессов быстродействием и объемом оперативной памяти. Пара X11R6—Linux весьма неплохо работает на так называемых бездисковых комплексах. Рабочие станции в таких комплексах – самые настоящие X-терминалы, они не имеют жестких дисков. Вся работа происходит на центральном компьютере, с которого на рабочую станцию загружаются по сети урезанный вариант системы, достаточный для запуска X-сервера, и сам X-сервер. В таких комплексах администрировать нужно одну только центральную машину, они надежнее компьютерных залов и, что немаловажно, стоят дешевле, причем в качестве X-терминалов можно использовать и довольно маломощные, "пожилые" компьютеры.
Виртуальный сервер
Одно из многих достоинств X-протокола заключается в том, что X-сервером может служить любая программа, исполняющая X-запросы, а работает ли она на самом деле с каким-нибудь графическим устройством или только притворяется – неважно. Протоколом X11R6 пользуется сервер печати Xprt, который выводит на принтер все X-запросы или Xvnc – X-сервер, управлять которым по специальному протоколу можно с нескольких машин. С помощью Xvnc можно устраивать показ работы какого-нибудь X-клиента по сети – при этом все пользователи одновременно смогут гонять по экрану один и тот же указатель мыши (что, конечно, можно и запретить).
Виртуальный X-сервер может вообще никаких действий не выполнять, а только передавать X-запросы куда-нибудь дальше, например, "настоящему" X-серверу. Так поступает демон Secure Shell, sshd (программа терминального доступа, о которой уже шла речь в этой лекции), переправляя X-запросы X-серверу в зашифрованном виде. Этим свойством sshd можно воспользоваться, если сообщение по X-протоколу между двумя компьютерами невозможно (запрещено межсетевым экраном), или администратор считает такое соединение небезопасным:
methody@sakura:~ ssh methody@fuji
methody@fuji's password:
Last login: Sat Dec 25 13:26:40 2004 from localhost
methody@fuji:~ $ xcalc
Error: Can't open display:
methody@fuji:~ $ export DISPLAY=sakura:0
methody@fuji:~ $ xcalc
Error: Can't open display: sakura:0
methody@fuji:~ $ logout
Connection to fuji closed.
methody@sakura:~ ssh -X methody@fuji
methody@fuji's password:
Last login: Sun Dec 26 11:13:08 2004 from sakura.nipponman.ru
methody@fuji:~ $ echo $DISPLAY
localhost:10.0
methody@fuji:~ $ xcalc
# работает :) !
Допустим, Мефодий хочет запустить X-клиент (например, xcalc) на другой машине в локальной сети – fuji, где у него есть учетная запись (тоже methody). После всех операций, проделанных в примере, на экране X-сервера на локальной машине Мефодия (за которой он сидит), появится еще одно окно xcalc; при этом этот xcalc в действительности запущен на машине fuji и все вычислительные операции выполняются именно там.
Демона SSH заводит виртуальный X-сервер на удаленной машине, причем обычно номер_сервера заводится таким, чтобы не пересекаться с X-серверами, которые могут быть запущены на этой машине (в примере номер_сервера равен 10). Виртуальный sshd-X сервер принимает все X-запросы с того же компьютера и передает их – в зашифрованном виде – на компьютер, где запущен ssh и невиртуальный X-сервер. Здесь все X-запросы вынимаются из SSH-"водопровода" и передаются местному серверу, как если бы они исходили от местного X-клиента (так оно и есть: этот клиент – ssh).

XFree86 и XOrg
Наиболее распространенная версия реализации X11R6 называется XFree86. Эта графическая подсистема изначально проектировалась как реализация X11R5 для машин архитектуры i386 – самых распространенных на сегодня персональных компьютеров. Главная особенность этой архитектуры – бесчисленное многообразие устройств графического вывода (видеокарт) и непрестанное нарушение их разработчиками всех мыслимых стандартов. Поэтому главной задачей создателей XFree86 было устроить гибкую структуру компоновки и настройки X-сервера в соответствии с подвернувшимся под руку устройством графического вывода, а заодно и ввода, потому что клавиатур, мышей и заменяющих их устройств на свете тоже немало. Сегодня XFree86 существует для многих архитектур и многих операционных систем.
В последние годы параллельно с XFree86 развивается основанная на тех же исходных текстах X Window System графическая подсистема XOrg. До недавнего времени по спектру поддерживаемого оборудования, архитектур и функциональности XOrg мало чем отличалась от XFree86, и сейчас они тоже примерно эквивалентны с точки зрения пользователя. Однако направления развития этих двух проектов, состав их разработчиков и лицензионная политика несхожи. В ближайшем будущем вполне вероятно, что Xorg обгонит XFree86 и по возможностям, и по частоте использования.
Конфигурация X-сервера
Чтобы приспособить графическую подсистему (в любой реализации) к имеющемуся оборудованию, требуется организовать соответствующий профиль. профиль графической подсистемы находится в каталоге /etc/X11, основной конфигурационный файл XFree86 называется XF86Config-4– именно его считывает при запуске X-сервер. Конфигурационный файл XOrg называется xorg.conf, а при его отсутствии используется файл XF86Config.
Мы рассмотрим конфигурацию графической подсистемы на примере XFree86. Файл XF86Config-4 структурирован: состоит из нескольких обязательных разделов, которые могут следовать в любом порядке. В раздел объединяется часть профиля, связанная с одной из сторон деятельности X-сервера. Каждый раздел имеет такую структуру:
Section "НазваниеРаздела"
КлючевоеСлово "Параметры"
. . .
EndSection
Внутри раздела содержатся записи, каждая из которых занимает обычно одну строку и задает значение для одного из параметров профиля XFree86. В начале записи стоит Ключевое Слово, за которым следуют Параметры, количество и формат которых зависит от ключевого слова. Ниже приводится список обязательных разделов с краткими аннотациями, объясняющими для чего они служат:
Files         Пути к файлам с ресурсами, необходимыми X-серверу
ServerFlags   Общие параметры X-сервера
Module        Расширения, которые следует загрузить
InputDevice   Описание устройств ввода
Device        Описание устройства вывода (видеокарты)
Monitor       Описание монитора
Modes         Описание видеорежимов
Screen        Описание экрана (связывает монитор и видеокарту)
ServerLayout  Конфигурация сервера
Почти каждый из перечисленных разделов может присутствовать в конфигурационном файле в нескольких экземплярах, например, может быть несколько разделов (InputDevice), описывающих разные устройства ввода (разные мыши и клавиатуры). Однако эти разделы не равноправны, а образуют иерархическую структуру, самым главным (корневым) элементом которой является конфигурация сервера (ServerLayout). В этом разделе указывается, какие именно из описанных в файле устройств ввода (разделы InputDevice, как минимум два – для клавиатуры и мыши) и вывода (Screen, который связывает в единое устройство вывода монитор и видеокарту, ссылаясь на их описания в соответствующих разделах) будут задействованы при работе X-сервера. В каждом разделе присутствует строка "Identifier "идентификатор"". Именно эта строка используется для выбора нужного из однотипных устройств в разделе "ServerLayout". Например, на машине, где работает Мефодий, общая конфигурация сервера выглядит так:
Section "ServerLayout"
Identifier  "layout1"
Screen      "screen1"
InputDevice "Mouse1" "CorePointer"
InputDevice "Keyboard1" "CoreKeyboard"
EndSection
Соответственно, при запуске сервера будут использованы тот раздел Screen, в котором содержится запись "Identifier "screen1"", мышь "Mouse1" и клавиатура "Keyboard1".
Чтобы разобраться в подробностях каждого раздела, требуются определенные знания о работе и характеристиках устройств ввода и вывода, поэтому здесь мы не будем приводить конкретные примеры. Подробно о формате XF86Config можно прочитать в соответствующем руководстве XF86Config(5). Для многих пользователей будет достаточно профиля графической подсистемы, созданного одним из существующих мастеров, самый известный из которых – xf86config. Во многих дистрибутивах имеются собственные полуавтоматические утилиты настройки X11. С их помощью можно создать более или менее подходящий профиль, не вникая в тонкости, нередко – непосредственно при установке системы. Во всяком случае, у пользователя всегда остается возможность корректировать профиль вручную, отредактировав конфигурационный файл. Простой конфигурационный файл можно получить, запустив X-сервер с ключом - configure из-под суперпользователя. При этом в текущем каталоге будет создан файл XF86Config.new, в котором X-сервер сохранит результаты автоматического определения внешних устройств.
Модули и расширения
Требование гибкости привело к тому, что в реализации XFree86 и XOrg графическая подсистема стала совсем уже похожа на операционную систему. Сам X-сервер играет роль ядра. Запускаясь, сервер подгружает драйверы – специальные компоненты, работающие с выбранной видеокартой, и модули – компоненты, расширяющие функциональные возможности сервера (в конфигурационном файле XF86Config необходимые модули перечисляются в разделе Modules). Есть весьма нужные расширения, вроде glx (высокоуровневые функции трехмерной графики) или freetype (поддержка шрифтов TrueType), а есть экзотические, которые иногда могут понадобиться, например, RECORD, позволяющее записывать, а после – "проигрывать" все происходящие с сервером события.
Расширения называются так еще и потому, что их возможности расширяют сам протокол X11R6. Вместо того, чтобы изменять протокол всякий раз, когда в голову придет очередная идея, создатели X11 предусмотрели стандартный способ дополнения этого протокола. При этом X-клиент, желающий воспользоваться определенным расширением, всегда может спросить у X-сервера, поддерживается ли оно, и действовать по обстановке.

X-приложения
Программный продукт, использующий X11, называется приложением (application, другое значение – "применение"). Если считать, что сами графические возможности уже реализованы X-сервером и библиотеками, то программа и на самом деле окажется приложением к системе, и вся ее заслуга будет состоять в том, что она применила эти возможности для решения своей задачи.
Эмулятор терминала
С графикой или без, основным интерфейсом управления Linux была и остается командная строка. X11, предлагая иной способ взаимодействия с компьютером, не должна лишать пользователя возможности работать с самой системой испытанным и эффективным методом – через терминал. Поэтому первое совершенно необходимое X-приложение должно предоставлять возможность доступа к терминалу в X Window System.
Задача дать пользователю X11 командную строку решается довольно легко. Нужно завести X-приложение, окно которого работает аналогично
окну терминала: передает символьную информацию от пользователя системе и обратно. Делается это уже описанным в лекции Mount-механизмом псевдотерминалов tty/pty (или pts/ptmx): X-приложение получает во владение специальное устройство типа pty, связанное по вводу и выводу с терминальным устройством типа tty, с которым работает shell. Общее название таких программ – эмулятор терминала для X11 (xterm). Мефодий может запустить xterm все из той же виртуальной консоли, в которой определено значение переменной окружения DISPLAY, и получить доступ к командной строке уже из графической оболочки.
В левом верхнем углу открылось окно xterm, которое легло "поверх" открытого ранее xcalc. В открывшемся окне xterm Мефодий увидел привычное приглашение командной строки bash: теперь из этой командной строки можно выполнять любые команды, в том числе и запускать новые X-приложения, например, еще один xterm. Чтобы при этом избежать наложения окон друг на друга, можно запустить xterm с параметром "-geometry +150+150", что заставит X-сервер выдать ему окно, верхний левый угол которого отстоит на 150 экранных точек (пикселей) от левой границы экрана, и на те же 150 – от верхней. В этом xterm значение DISPLAY унаследовано от родительского процесса и равно ":0", так что окна всех запущенных из него X-приложений откроются на этом же экране.
Не следует путать программу xterm со способом организации рабочей станции (так называемый "X-терминал"): термины эти созвучны, но относятся к разным областям знаний. Нередко бывает, что на экране X-терминала (компьютера) есть окно терминала X11 (программы xterm). XTerm передает сигналы как настоящий терминал, имеет богатый набор управляющих последовательностей (унаследованный от устройства "DEC VT102/VT220"), а вдобавок позволяет воспользоваться всеми преимуществами графической среды: выбрать шрифт, запомнить текст на экране (даже тот, который уже исчез с экрана) и многое другое.
Кстати сказать, копирование текста при помощи мыши – свойство не только XTerm. На самом деле любое окно, зарегистрированное в X11 как текстовое, позволяет отметить (при постоянно нажатой первой кнопке или последовательными нажатиями третьей) часть текста. Выделенный текст можно немедленно вставить в любое окно текстового ввода нажатием второй кнопки. Утилита xcutsel предоставляет возможность работы с буфером обмена cutbuffer), в котором текст может храниться сколь угодно долго.
Сеанс работы с X11
Как догадался Мефодий, команда startx делает несколько больше, чем просто запуск X-сервера; она, помимо того, запускает несколько X-приложений. Для удобной работы в X11 пользователю прямо при запуске графической подсистемы потребуется сразу несколько приложений. Во-первых, нужно запустить приложение, которое позволит управлять окнами (как минимум перемещать их), чего не делает сам X-сервер, такие приложения называются диспетчерами окон и будут обсуждаться немного позднее. Кроме того, полезно сразу запустить разные мелкие программки, вроде индикатора загрузки системы xload или экранных часов xclock. Сам X-сервер не мешает настроить с помощью xset (можно поменять курсор, звуковой сигнал, переименовать кнопки мыши). Одним словом, пользователю, как правило, нужен небольшой стартовый сценарий, который запускался бы вместе с X-сервером.
С другой стороны, сервер хорошо бы останавливать, когда он больше не используется. Это, конечно, относится к схеме без диспетчера экрана (xdm): пользователь работает с терминала, потом запускает X-сервер для выполнения графических программ, выполняет их и останавливает сервер, чтобы графическим устройством мог воспользоваться кто-нибудь другой. Стандартный способ аварийного завершения работы XFree86 (Ctrl+Alt+Backspace), во-первых, доступен только на XFree86, во-вторых, его можно отключить, а в-третьих, все запущенные приложения получат в этом случае сообщение о внезапной кончине сервера и тоже завершатся аварийно.
Если запускать не сам X-сервер, а некоторую оболочку вокруг него, называемую startx, то алгоритм работы будет такой. Сначала запустится X-сервер и сформируется значение переменной окружения DISPLAY. Затем запустится сценарий .xinitrc, находящийся в домашнем каталоге пользователя, а если такого нет – системный стартовый сценарий /usr/X11R6/lib/X11/xinit/xinitrc. Предполагается, что X-сервер будет работать до тех пор, пока выполняется .xinitrc. Когда все команды из .xinitrc отработают, его выполнение завершится, а вместе с ним завершится и работа сервера. Поэтому рекомендуется все X-приложения из .xinitrc, кроме последнего, запускать в фоне, чтобы командный интерпретатор не дожидался окончания их работы. В этом случае с завершением работы последнего приложения из .xinitrc завершится и сам X-сервер. Последней программой в стартовом сценарии может быть xterm, как это сделано в стандартном xinitrc, или диспетчер окон. Для завершения xterm (а с ним и всего сеанса работы X11) достаточно послать "^D" запущенному в нем shell, а окновод обычно имеет какую-нибудь кнопочку или менюшку "Exit". Программа, с завершением которой завершается сеанс X11, называется лидером сеанса (session leader).
Лидер сеанса может быть указан и в качестве параметра startx в командной строке, например, по команде startx /usr/X11R6/bin/xterm будет открыт сеанс X11, лидером которого станет xterm – его окно откроется при запуске на экране X-сервера.
Диспетчер экрана организует сеанс работы с X11 сходным образом. Единственное отличие – в том, что ко времени запуска startx вручную пользователь уже имеет настроенное окружение (этим занимается стартовый командный интерпретатор), а после регистрации в диспетчере экрана – нет. Поэтому стартовый сценарий нужно запускать другой – .xsession. На самом деле, и сам X-сервер необходимо перезапускать при использовании xdm. Несмотря на то, что пользователи взаимодействуют только с X-сервером, не используя виртуальные консоли, было бы неудобно и небезопасно сохранять какие бы то ни было настройки, сделанные одним пользователем, ко времени работы другого. Самое неприятное – это так называемый "клавиатурный вор" (keyboard grabber), программа, притворяющаяся окноводом – для того лишь, чтобы запоминать все, что пользователь ввел с клавиатуры (злоумышленников интересуют, как правило, пароли).
Нарушения безопасности легко избежать, если не использовать xhost (авторизацию на основе адреса) и не доверять X-серверу, запущенному не при вас. Можно доверять автоматически запускаемой в сеансе программе xauth, которая связывается с X-сервером и записывает в файл ~/.Xauthority специальный ключ доступа. Все X-приложения пользуются библиотекой libX11, которая обязательно обращается к этому файлу. Таким образом, X-приложение может воспользоваться X-сервером, если оно знает его адрес (указанный в переменной окружения DISPLAY или переданный ключом -display) и авторизовано сервером (по адресу компьютера или по ключу доступа в ~/.Xauthority).
Ресурсы X11
X-приложения создаются с помощью разнообразных готовых инструментариев. Большая их часть разрабатывается независимыми авторами по всему миру (это общее свойство свободного ПО, см. лекцию 18), но библиотека самого низкого уровня, "X Lib", и несколько более высокоуровневых библиотек с давних пор включаются в основной дистрибутив X11. Из них наиболее примечательна "X Toolkit" (Xt), организующая из стандартных окон X11 оконные примитивы (widgets).
Дело в том, что каждый объект X11 обладает некоторым набором свойств, вроде размера окна, цвета фона или текстового содержимого. Для удобства доступа примитивы Xt, реализованные поверх объектов Xlib, имеют собственные имена (у каждого объекта – свое) и фамилии (одинаковые у всех объектов одного класса). Более того, программа, написанная на Xt, имеет карту объектов, в которой указано, какой объект внутри какого находится, и приведены имена объектов и их классов. Посмотреть структуру запущенного X-приложения можно с помощью программы editres ("Commands/Get Tree"). Например, программа xlogo состоит из трех примитивов: xlogo (класс XLogo) и вложенных в него xlogo.xlogo (класс Logo) и shellext (неоконный, класс VendorShellExt). Мало того, свойства этих примитивов можно подменить прямо в работающей программе. Можно, например, на время работы перекрасить фон xlogo в красный цвет.
Xlib, со своей стороны, предоставляет универсальный способ хранить такие настройки в файле. Многие приложения хранят свои настройки по умолчанию в /usr/X11R6/lib/X11/app-defaults/ИмяКласса (в некоторых системах этот каталог перенесен, как ему и подобает, в /etc/X11). ИмяКласса – это имя класса самого главного окна этого приложения. Пользователь может дополнить настройки ресурсов, которые сервер накапливает при старте, при помощи команды xrdb -merge файл_настроек или переписать их заново (ключ "-load"). Приложению остается только вызвать специальную функцию Xlib, которая считывает настройку с определенным именем из таблиц сервера. Если xrdb не запускалась ни разу (в том числе и в стартовом сценарии), запрос приложения будет направлен не в таблицу сервера, а непосредственно в файл ресурсов .Xdefaults1), лежащий в домашнем каталоге. В этом случае для изменения настроек не надо запускать xrdb.
Xt добавляет в эту процедуру иерархию ресурсов. Как это можно наблюдать в editres, при задании свойства ресурса используются четыре конструкции: имя ресурса, имя класса, разделитель ".", означающий, что один ресурс непосредственно вложен в другой и разделитель "*", означающий, что ресурс в конце концов вложен в другой (возможно, по цепочке). Например, для задания цвета фона в программе xload можно использовать именование xload.paned.load.background (это все по именам). Можно попробовать единым махом изменить цвет фона всех примитивов этой программы, записав в .Xdefaults (или передав xrdb) строку вида "XLoad*background: midnightblue".
Если в .Xdefaults есть несколько строк, удовлетворяющих имени ресурса, то имена собственные имеют преимущество над классами, а "." – над "*". Так что запись вида "*Text*background: peachpuff" повлияет только на те примитивы класса Text и вложенные в них, для которых нет более строгого указания (например, "*Text.background" или "XConsole*Text*background"). Обратите внимание, как поэтично называются порой цвета в X11! Посмотреть таблицу цветов можно командой xlscolors.
К сожалению, Xt – все-таки довольно старая библиотека, не во всем следующая новым веяниям в области графического интерфейса. Для быстрой разработки оконных программ нужны разнообразные и мощные инструменты, которые манипулируют понятиями, далеко ушедшими от стандартного "окно–меню–кнопка". Если такие инструментарии написаны с применением Xt (например, Xm, open Motif, Xaw, Athena Widget), их настройки можно поселить в .Xdefaults. Проблема еще и в том, что структуру классов Xt неудобно использовать при программировании на языке C++, а именно на нем сейчас пишется большинство оконных приложений. Так что самые мощные инструментарии для X11 – Qt ("The Q Toolkit") и GTK ("The GIMP Toolkit") – не используют App-defaults.

Диспетчер окон

Задача диспетчера окон

X-сервер берет на себя ответственность только за выдачу X-приложению области для ввода-вывода и управление фокусом окна, но не занимается никакими манипуляциями по изменению этого окна: перемещением, изменением размера, сворачиванием и т. п. Мефодий уже наблюдал X-сервер, к которому присоединено два клиента, чьи окна перекрываются: два черно-белых окна друг на друге, и их нельзя ни растащить по углам, ни сжать. X-сервер умеет очень ловко манипулировать окошками, но сам никогда ничего не делает – он дожидается команды от пользовательской программы. А какая программа станет самостоятельно отслеживать перекрытие окон, фокус, заниматься изменением размера, перемещением и тому подобным? Ведь основная задача программы может быть совсем другой...
Ответ очевиден: этим должна заниматься программа, основная задача которой состоит в том, чтобы отслеживать перекрытие, изменять размер, двигать, превращать в иконку и так далее. По совместительству эта же программа будет рисовать при окнах всякие украшения: рамочки, заголовки, кнопки и меню управления – словом, делать все что нужно для организации логики управления окнами. Для этого придется также обрабатывать практически все события, передаваемые от устройств ввода, и многочисленные "подсказки" от приложений относительно того, какими они хотят видеть собственные окна. Это X-приложение называется диспетчером окон (window manager).
Диспетчер окон. Программа, основная функция которой – обеспечивать манипуляции с окнами: перемещение, изменение размера, сворачивание и т. п.
Благодаря стандартному протоколу X11 появилось такое множество диспетчеров окон для X Window System, что перечислить их все просто невозможно. Они различаются видом и кругом возможностей для манипулирования окнами: от самых простых (рамочка вокруг окна позволяет двигать его, изменять размер и поднимать из глубины; вот собственно, все) до весьма сложных (виртуальные экраны, анимированные полупрозрачные меню, панели инструментов, причудливой формы украшения на окнах; сами окна ползают по экранам, кувыркаются, растворяются как утренний туман; все это лязгает, попискивает и разговаривает приятным женским голосом). Когда Мефодий в первый раз запустил команду startx, тут же была запущена утилита wm-select, которая предложила ему выбрать, какой из установленных в его системе диспетчеров окон запустить.
Выбор диспетчера окон на свой вкус – очень непростое и вдумчивое занятие. Мы советуем просто соблюдать меру, сообразуясь с тем, для чего вы используете оконную систему: обилие ярких декораций отвлекает от работы (а если они вдобавок шевелятся?), а слишком строгий минимализм ее усложняет. Имейте в виду, что чем причудливее и многообразнее возможности окновода, тем труднее будет его полностью настроить именно под себя. Скорее всего, вы просто согласитесь пользоваться уже настроенными – общеупотребительными – возможностями, не доводя их до совершенства.

Работа с окнами

Совершенно необязательно начинать сеанс работы в X11 с запуска диспетчера окон – его можно запустить в любой момент. Например, Мефодий может к уже запущенному им X-серверу подключить любой диспетчер окон, запустив его все из той же виртуальной консоли. Например, чтобы запустить WindowMaker, достаточно выполнить команду wmaker.
С запуском диспетчера окон экран X-сервера заметно преобразился: одноцветный фон сменился изображением, по углам возникли квадратные кнопки, а вокруг окна xterm образовалась рамка с названием окна и кнопками. Эта рамка – "органы управления" окном, так называемые оконные примитивы (их собственное имя – "widgets" – сокращение от "window gadgets", "оконные безделушки"). "Ухватившись" мышью за рамку, Мефодий поменял размеры окна, а, нажав правую кнопку мыши на заголовке окна, – увидел меню, состоящее из списка операций, которые можно произвести над этим окном. Все эти возможности предоставлены диспетчером окон WindowMaker.

Удобства

Однако помимо своей основной функции – операций с окнами – многие диспетчеры окон владеют массой других приемов по упрощению работы пользователя и повышению наглядности. Самые главные из таких удобств – кнопки для запуска типичных задач: нажатие на кнопку заменяет собой выполнение команды в эмуляторе терминала. Команда может быть длинной или забываться, а тут одно нажатие и кнопка все время на виду. Это удобно для привычных повседневных действий. Например, в правом верхнем углу экрана WindowMaker присутствует кнопка с изображением монитора – для запуска xterm. Вторая важнейшая возможность – общее меню, в котором классифицированы доступные в системе приложения. При помощи такого меню пользователь может найти и запустить нужную прикладную задачу.
Большое удобство, предоставляемое очень многими диспетчерами окон для X11, – виртуальные экраны. Когда пользователь работает сразу с несколькими задачами, ему обычно приходится открывать много окон, так что они уже не умещаются без наложения на физической поверхности экрана. Чтобы при этом было удобно переключаться между задачами,
можно использовать некоторые специально для этого предназначенные функции диспетчера окон: сворачивание и разворачивание, перекладывание окон "выше" и "ниже" в стопке, список активных задач и т. п. Но еще удобнее было бы не перекладывать окна, а разложить их на большей, чем размеры экрана, поверхности – виртуальном экране. Таким образом, настоящий экран – это небольшое "окошко", в котором можно видеть только часть виртуального, а при необходимости можно это окошко сместить в другой конец "виртуального стола", где лежат окна с другими задачами.
Диспетчер окон организует виртуальный экран сам: X-сервер при запуске диспетчера окон выдает ему одно окно размером во весь экран, так что все остальные окна оказываются внутри него, и диспетчер окон уже сам решает, когда и кому передать фокус, как обойтись с окнами и т. п. При этом он вполне может "делать вид", что его экран больше экрана монитора, по определенной команде (переключиться на другой конец виртуального экрана) запоминая и пряча текущее расположение окон и заменяя его другим, до этого хранившимся в памяти. Конфигурация виртуального экрана может быть любой – она зависит только от логики работы диспетчера окон. виртуальный экран может состоять из нескольких частей размером в реальный экран, поставленных в ряд, доступных по номерам, организованных в виде прямоугольника и т. п. Бывают даже трехмерные виртуальные экраны.
Виртуальные экраны есть и в WindowMaker. Переключение между ними осуществляется при помощи специальной кнопки в левом верхнем углу экрана или сочетания клавиш Alt+N, где N – номер виртуального экрана. Однако чтобы не забывать, где лежит какое окно, полезна возможность окинуть одним взглядом все разложенное на виртуальном экране. окно, отображающее в уменьшенном масштабе вид виртуального экрана и позволяющее перейти к нужной части, называется пейджер и относится к распространенным в диспетчерах окон удобствам.

Настройка диспетчера окон

Удобство графического интерфейса – понятие очень субъективное. При этом технологически безразлично, рисовать ли кнопки в левом верхнем углу или в правом нижнем, какой цвет и шрифт использовать в меню и т. п. – все это составляет профиль диспетчера окон. Поэтому в подавляющем большинстве диспетчеров окон существуют более или менее развитые возможности изменить внешний вид и оформление графической среды. В WindowMaker для этого используется специальная утилита с графическим интерфейсом (Мефодий может ее вызвать при помощи самой верхней кнопки в левом верхнем углу экрана). В других диспетчерах окон, как, например, в очень развитом fvwm, профиль может просто храниться в конфигурационном файле (~/.fvwm2rc). Для изменения внешнего вида fvwm следует редактировать этот файл.
Среди диспетчеров окон в тяжелых весовых категориях выступают и fvwm2 (множество функций), и Enlightenment (настоящая игрушка), и WindowMaker, и некоторые другие. Человеку, проводящему рабочее время за экраном компьютера, важен комфорт на рабочем месте, поэтому всякая мелочь или ее отсутствие может иметь решающее значение при выборе того или иного диспетчера окон.

Рабочий стол

С появлением универсальных высокоуровневых инструментов стала приближаться к осуществлению идея полного воплощения метафоры "рабочего стола", впервые реализованная в системах семейства MacOS. Смысл рабочего стола в том, чтобы предложить принципиально иной способ взаимодействия человека и компьютера – способ, основанный на манипуляции единичными именованными объектами. Каталоги превращаются в "папки с документами", причем каждый тип документов можно "открыть" с помощью специального "документатора". Программы превращаются в эдакие вместилища абстрактных функциональностей: "Internet", "Почта", "Видео" и т. п. Рабочий стол особенно необходим человеку, чья область деятельности далека от компьютерного дела, для кого он – не вычислительная машина, а инструмент решения отдельных – типовых и, чаще всего, непрофильных – задач.
Компьютер так уверенно вошел в каждый дом, что давно уже стал бытовым прибором для игр, чтения электронной почты, просмотра WWW, а в последнее время – еще и музыкальным центром и видеопроигрывателем. Грешно требовать от садящейся за клавиатуру домохозяйки или какого-нибудь оболтуса строгого следования принципам проективной системы. Лучше дать им в руки красивую и сравнительно безопасную игрушку, которая способна удовлетворять их бытовые нужды. Таких игрушек для X11 несколько. Две мощные среды "офисного" плана – KDE (основанное на Qt переосмысление коммерческой среды CDE) и Gnome (основанная на GTK) – содержат все необходимое для работы (включая собственные офисные приложения и средства просмотра WWW). Или, например, среда XFCE (основанная также на GTK) – крепко сколоченный минималистский вариант CDE, простой и ясный, как выдвижной ящик.
Мефодий выбрал одну из таких игрушек – KDE, начав с оформления рабочего стола на свой вкус. Когда ему, наконец, наскучило перекрашивать меню и загромождать рабочий стол безделушками, он попробовал заняться делом. В примере отображен снимок экрана в один из моментов его работы, когда он попытался воспользоваться для работы с файлами специально разработанной для KDE программой (konqueror, которая служит заодно и броузером) вместо уже привычной ему командной строки. При этом Мефодия насторожило время, которое ему потребовалось на выполнение вполне привычных простейших операций над несколькими файлами и каталогами: для каждого пришлось делать отдельное движение мышью, да и в целом все стало происходить гораздо медленнее, чем обычно, а компьютер то и дело принимался хрустеть жестким диском.
До сей поры Мефодий считал, что его – не такой уж новый – компьютер вполне подходит для работы в Linux, и ничто этому утверждению не противоречило. Желая проверить, чем же занимается система, он запустил команду top, нажал "M", для того чтобы посмотреть, какие процессы занимают больше всего памяти, и обнаружил довольно неприятную, хотя и вполне терпимую картину:
Первое, что бросилось ему в глаза – множество процессов, запущенных явно средой KDE (кому же еще может принадлежать программа kdeinit?). Мефодий подсчитал число процессов, начинающихся на "kde" (ps ax | grep kde | grep -v grep | wc -l) – их оказалось 17 штук. Каждый из этих процессов затребовал у системы по три-четыре мегабайта памяти (поле SIZE), из которых полтора-два (поле RSS) немедленно использовал. Не так уж и много – если бы такая программа запускалась одна. Но две дюжины kdeinit вполне способны израсходовать всю оперативную память компьютера, если объем его физической памяти составляет, как на компьютере Мефодия, 64 мегабайта (из них порядка девяти мегабайтов заняло ядро – эта память не отображается в поле mem – и сколько-то уходит на сам X-сервер и прочие программы, не принадлежащие Мефодию).
Впрочем, даже в таком состоянии Linux продолжает работать довольно-таки бодро. Дело в том, что большинство из этих процессов (все, кроме самого top, об этом говорит строка "1 running") в данный момент неактивны (sleeping). Большинство полученных ими ресурсов система давно уже отправила в область подкачки (swap) на диске. Затруднения начнутся, если несколько неактивных программ "проснутся": система начнет поднимать из swap их ресурсы, а чтобы для них хватило места в оперативной памяти – откачивать туда память других программ (отсюда и неожиданная дисковая активность, на которую Мефодий обратил внимание). Хуже всего, если для работы всех активных процессов одновременно не хватает места – тогда процесс откачки-закачки будет отнимать большую часть процессорного времени, и для полезных задач его просто не останется. Определить такую ситуацию (она называется "дребезг", trashing) можно по высоким значениям полей system , а еще по постоянно ненулевым значениям в полях si и so команды vmstat:

procs      memory             swap     io  system      cpu
r b w swpd   free buff cache si so  bi bo  in  cs us sy id
0 1 0 106092 1352 1168 19380 14 10 265 33 127 407 14  4 82

Этот опыт произвел на Мефодия отрицательное впечатление, и он решил организовать себе графическое рабочее место на основании какого-нибудь менее громоздкого инструмента. Впрочем, провести границу, где заканчиваются обязанности диспетчера окон и начинаются ухищрения рабочего стола, очень трудно. Видимо, разумно считать, что диспетчер окон делается средой рабочего стола, когда появляются пользовательские приложения с использованием его особых свойств и его библиотек. Если главная задача рабочего места – запускать xterm, то достаточно даже очень старого диспетчера окон twm (он всегда есть в составе XFree86, но редко используется по причине некрасивого, "плоского" оформления интерфейса). Вместо него можно использовать диспетчеры, подобные icewm или fluxbox, обладающие более широкими возможностями и при этом нетребовательные к ресурсам. Если необходимо просто и незамысловато обеспечить доступ к основным пользовательским X-приложениям, подойдет XFCE. Наконец, диспетчеры, подобные WindowMaker или fwvm, предоставляют множество возможностей и гибко настраиваются, не "вытягивая" за собой ресурсоемких программных структур, используемых в KDE или Gnome.
Поразмыслив, Мефодий решил остановиться на WindowMaker: система меню показалась ему приятной для глаз, а способ быстрого запуска – удобным. Кроме того, его позабавили "активные иконки", шевелящиеся в момент запуска соответствующего приложения.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика