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

 

Графическая подсистема X11

Унификация и разделение графических ресурсов
В лекции 7 отмечалось, насколько UNIX не требователен к интерфейсу, когда речь идет об управлении системой. Типичный способ администрирования UNIX-сервера – удаленная работа по сети, причем (спасибо Internet) удалиться от компьютера можно сколь угодно далеко, лишь бы связь была достаточно надежной для терминальной работы. Это означает, что все прочие возможности взаимодействия машины с человеком понимаются системой как ресурс, который следует распределять между пользовательскими задачами так же, как и оперативную память, дисковое пространство или, скажем, ресурсы подсистемы печати.
Напомним три задачи, которые решает операционная среда относительно ресурсов: унификация, разделение и учет доступа. С унификацией все более или менее понятно: на свете существует множество графических устройств, управление которыми на низком уровне – задача совсем не для пользователя, тем более что каждый вид устройства управляется посвоему. Низкоуровневые команды система должна взять на себя, а пользователю предоставить графические примитивы (вроде функции рисования линии), которые будут работать всегда одинаково.
Выходит, что пользователю этого ресурса недостаточно представлять графический адаптер как большую страницу видеопамяти, частично отображаемую на устройстве вывода – мониторе: ведь пользователю диска мало представлять его в виде массива секторов! Разница в том, что этого было бы недостаточно и самой системе, так что в UNIX введено понятие файловой системы, объекты которой значительно сложнее, чем «сектор» или «диск». А что касается графики – у UNIX нет ни предпочтений, ни особых видов на эти способности машины. Значит, со стороны системы разумно организовать именно доступ к устройству, а требуемую объектную модель пусть реализует пользовательская задача.
Такая задача будет, конечно, отличаться от пользовательских утилит и программных продуктов. По своим правам она скорее будет сродни демонам. Она получит единоличный доступ к устройству, а по отношению к пользователю сама окажется операционной средой, организуя на свой лад унификацию, разделение и учет доступа к графическим ресурсам в объектной модели. Поэтому весь комплекс программ для работы с графическими устройствами принято называть графической подсистемой.
Неизбежно удвоение функций: система занимается аутентификацией и авторизацией – и графическая подсистема вынуждена делать то же самое, раз уж ей вменяется в обязанность «разделять». Более того, в отличие от той же файловой системы, само понятие разделения ресурса графического ввода или вывода представляется, мягко говоря, неочевидным. Как разделить между пользователями мышь? экран монитора? Видимо, придется признать, что с этой стороны графической подсистемы находится один человек, а вот каким субъектам принадлежат программы, которые ею пользуются, графической подсистеме неизвестно. Об учете графических ресурсов говорить вообще странно, однако, как мы увидим в дальнейшем, некоторое рациональное зерно в этом есть, и подход UNIX позволяет его использовать.

The X Window System
Оконный интерфейс
Заметим: из того, что система использует только один способ взаимодействия с человеком, совсем не следует, что и пользовательские задачи должны подлаживаться под него. В частности, если машина обладает графическими средствами ввода/вывода, с их помощью можно организовать совершенно иной по своей сути интерфейс – оконный. На сегодня это один из немногих продуманных способов организации интерфейса, восходящий, строго говоря, к процедурной организации среды (см. ). Но опять-таки, из проективности системы не следует проективность всех ее приложений. Даже наоборот: проективная система – универсальный инструментарий для решения любых классов задач, так что именно с ее помощью должна хорошо решаться задача построения специализированной процедурной системы.
Оконный интерфейс определяет не только основные элементы взаимодействия с пользователем («окошки–меню–кнопочки»), но и структуру авторизации в подсистеме. Пространством ресурсов оконная система представляет экран. Экран – это прямоугольник, на котором отображаются команды графического вывода и организуется обратная связь с устройствами графического ввода. Пример обратной связи – указатель мыши. Сама мышь – довольно простое устройство ввода, способное передавать информацию о его перемещении и состоянии кнопок. Указатель же отображает мнение подсистемы об абсолютных координатах гипотетической «точки ввода».
Субъект оконной системы – не пользователь, что сидит за монитором (все равно он только один), а окно, представленное некоторой (как правило, прямоугольной) частью экрана. Внутри окна выполняются графические операции, и именно окна обрабатывают в свой черед поток данных от устройств ввода. Черед этот устанавливается с помощью синтетического понятия фокус: вводимые данные передаются только окну, «получившему фокус» от графической подсистемы, что по умолчанию происходит, когда указатель мыши попадает в часть экрана, занимаемую этим окном. В более сложном случае интерфейса окна могут перекрываться, частично занимая один и тот же участок экрана. Если дополнительно постановить, что каждое из них лежит на своей глубине, то самое «верхнее» будет отображаться полностью, и ему будет доступен для вывода и получения фокуса весь заказанный прямоугольник. Следующее за верхним окно может быть им «загорожено», тогда отображается только часть этого окна, которую видно из-под верхнего. Заметим, что выводить данные это окно может в пределах всего заказанного прямоугольника, просто видно может быть не все, и управление фокусом будет происходить на основании видимой части окна.
Как-то выделять окно, получившее фокус, а также предусматривать алгоритм перемещения окна по экрану или изменения глубины его «залегания» графическая система вовсе не обязана. Главное – предоставить такую возможность, а уж кто возьмет на себя труд эту возможность воплощать и как это будет выглядеть – вопрос частный, его в разных случаях лучше решать по-разному.
X-клиент и X-сервер
В начале 80-х существовала некая «Операционная система V» (The V System), а при ней – оконная подсистема W (следующая буква алфавита после V, а заодно – первая буква слова Window). К 1984 году совместными усилиями Массачусетского технологического института (MIT) и исследовательского отделения Digital Equipment Corporation (DEC) эту оконную подсистему сделали системно-независимой (crossplatforming, или, в американском стиле, X-platforming). Соответственно и название проекту дали – The X Window System (следующая буква алфавита после W. Обратите внимание на то, что все заглавные буквы X в этой лекции – латинские, а не русские Х). Проект был настолько наукоемок и настолько полно охватывал тогдашнюю область задач, связанную с графикой, что ему так и не возникло никаких серьезных альтернатив. X Window System (или X11) постоянно развивается, адаптируется к современным графическим устройствам и новым возможностям графического вывода. X11 использует традиционную оконную модель, помноженную на традиционную модель операционной среды, в которой в роли действующих субъектов выступают задачи.
Программа, которая отвечает за работу с устройствами графического ввода и вывода и обеспечивает при этом логику оконной системы, называется X-сервером (X Server, то есть сервер системы «Икс»). Если рассматривать X Window с точки зрения ОС, то X-сервер – это ядро. Подобно ядру, он выполняет низкоуровневые операции и взаимодействует с аппаратурой, ничего самостоятельно не предпринимая. Подобно ядру, он предоставляет задачам унифицированный интерфейс к этим низкоуровневым функциям, а также занимается разделением доступа (окно и фокус) к графическим ресурсам. X-сервер не интересует, отчего эти задачи вообще появляются и чем живут. Он только принимает запросы на выполнение графических действий и передает по назначению вводимые данные. Жизнеобеспечение процессов и даже способ передачи X-запросов – дело исключительно операционной системы, по отношению к которой и сам X-сервер является задачей.
Задачи, которые обращаются к X-серверу с запросами, называются X-клиентами. Обычно X-клиент сначала регистрирует окно (можно несколько), которое и будет для него полем ввода/вывода. Потом он сможет рисовать в этом окне и обрабатывать происходящие с ним события: активность устройств ввода и изменение свойств самого окна (размер, перемещение, превращение в иконку, закрытие и т. п.). X-клиент в UNIX – это процесс, запускаемый обычно в фоне (не связанный по вводу с терминальной линией). В самом деле, зачем процессу читать с терминала, когда для ввода он может использовать X-сервер? Если с X-сервером связаться не удастся, на стандартном выводе ошибок может появиться какое-нибудь сообщение, которое легко перенаправить в файл.
Клиент передает серверу X-запросы любым доступным ему способом. В разных версиях UNIX, например, могут использоваться различные объекты файловой системы (чаще всего так называемые сокеты, сходные по функциональности с двунаправленными каналами). Во многих случаях запросы передаются по сети, при этом неважно, какой именно транспортный уровень будет использован для соединения клиента с сервером (в современных системах это, чаще всего, сеть TCP/IP и протокол TCP). Главное, чтобы клиент посылал стандартные запросы, соответствующие определенному протоколу обмена данными. Кстати сказать, другое имя X Window System – X11 (или X11R6) – это просто номер версии X-протокола, устанавливающего стандарт на X-запросы. R6 обозначает номер подверсии (revision) и вполне может увеличиться, если X11R6 устареет настолько, что потребует очередного пересмотра протокола.
Итак, X-сервер запускается на одном компьютере, а X-клиенты вполне могут работать на других (причем на нескольких!), посылая ему запросы. С точки зрения человека, сидящего за (обратите внимание!) X-сервером, каждый такой клиент представлен в виде окна. Требования к аппаратуре на машинах, запускающих X-клиенты, будут сильно отличаться от требований к аппаратуре машины для X-сервера. Типичная машина с X-сервером – это рабочее место (workstation). Она должна быть оборудована качественными устройствами ввода/вывода – монитором, видеокартой, клавиатурой и мышью. Что же касается ее вычислительных способностей, то их должно быть достаточно для выполнения X-запросов, и только. Такой компьютер не обязан работать под управлением UNIX, на нем даже может вообще не быть операционной системы! В 80-е годы выпускались подобные устройства под названием «X-терминалы» (X terminal).
В отличие от машины с X-сервером, компьютер для запуска X-клиентов может совсем не иметь устройств графического ввода/вывода. Его задача в том, чтобы все X-программы и запустившие их пользователи не мешали друг другу работать. На такой машине нужна хорошо настроенная операционная среда, с достаточным для запуска многих процессов быстродействием и объемом оперативной памяти. Пара X11R6–UNIX весьма неплохо работает на так называемых бездисковых комплексах. Рабочие станции в таких комплексах – самые настоящие X-терминалы, они не имеют жестких дисков. Вся работа происходит на центральном компьютере, с которого на рабочую станцию загружается по сети урезанный вариант системы, достаточный для запуска X-сервера, и сам X-сервер. В таких комплексах администрировать нужно одну только центральную машину, они надежнее компьютерных залов и, что немаловажно, стоят дешевле, причем в качестве X-терминалов можно использовать и довольно маломощные компьютеры.

Аутентификация
Было бы странно, если бы X-сервер принимал и выполнял запросы ото всех клиентов подряд. Это, конечно, не так. Однако производить аутентификацию пользователя столь же строго, как это делает UNIX, довольно бессмысленно. Допустим, мы хотим дать доступ к системным ресурсам (в нашем случае к X-серверу) некоторому пользователю некоторой удаленной системы. На каком основании мы можем этот доступ открывать? Если того, что пользователь уже зарегистрирован в удаленной системе, нам достаточно, нет смысла регистрировать его еще раз в системе с X-сервером. Нужно только предусмотреть механизм разрешения доступа с определенных компьютеров. Этим и занимается утилита xhost, управляющая списком адресов, с которых разрешен доступ к X-серверу.
Если же мы не доверяем каждому пользователю удаленного компьютера, которому тот разрешил запускать X-клиент, значит, мы вообще не доверяем никакой ОС на удаленном компьютере. А вот собственной системе мы доверять должны, так что и обязанность отличать пользователя от пользователя можем спокойно переложить на нее. Авторизованному пользователю сообщается ключ сеанса, с которым его программы должны подступаться к X-серверу, если хотят, чтобы их обслужили. Как пользователь будет передавать это ключ на другие системы, X-сервера не касается. Нужно воспользоваться утилитой xauth, она как раз и манипулирует этими ключами, которых у пользователя может быть более одного.
X11 авторизует не пользователя, а каждое отдельное обращение к серверу с X-запросом. Обращения, использующие один и тот же ключ, принадлежат одному сеансу доступа (см. главу 9). ключ сеанса выдается пользователю, запустившему X-сервер, что подходит для естественной последовательности действий: войти в систему, запустить X-сервер, запустить несколько X-клиентов в рамках одного сеанса.
Однако часто встречается и другая ситуация: X-сервер запущен всегда, а работают с ним разные пользователи по очереди. Для этого при старте запускается специальный X-клиент, который заменяет (или просто вызывает) системную утилиту login: вводит (с графического устройства ввода) входное имя и пароль, отдает системе, та аутентифицирует пользователя и запускает нужные ему X-клиенты. Программа эта (xdm – X Display Manager – и его аналоги) запускается, конечно, от лица суперпользователя, причем с удаленного компьютера, а не с машины X-сервера. X-сервер можно запустить с указанием опрашивать по специальному протоколу XDMCP некоторый удаленный компьютер на предмет того, не хочет ли его xdm выдать аутентификационное окошко.
Виртуальный сервер
Одно из многих достоинств X-протокола – в том, что X-сервером может служить любая программа, исполняющая X-запросы, а работает ли она на самом деле с каким-нибудь графическим устройством или только притворяется – неважно. Протоколом X11R6 пользуется сервер печати Xprt, который выводит на принтер все X-запросы, или Xvnc – X-сервер, управлять которым по специальному протоколу можно с нескольких машин. С помощью Xvnc можно устраивать показ работы какого-нибудь X-клиента по сети, при этом все пользователи одновременно смогут гонять по экрану один и тот же указатель мыши (что, конечно, можно и запретить).
Виртуальный X-сервер может вообще никаких действий не выполнять, а только передавать X-запросы куда-нибудь дальше, например «настоящему» X-серверу. Так поступает демон Secure Shell (программы терминального доступа, упомянутой нами в лекции 8). Этим свойством sshd можно воспользоваться, если сообщение по X-протоколу между двумя компьютерами невозможно (запрещено межсетевым экраном) или вы считаете такое соединение небезопасным (в некоторых случаях ключ сеанса можно подсмотреть среди передаваемых по сети данных). Демон SSH заводит виртуальный X-сервер на удаленной машине: сервер принимает все запросы с того же компьютера и передает их – в зашифрованном виде – на компьютер, где запущен ssh и невиртуальный X-сервер. Здесь все X-запросы вынимаются из SSH-«водопровода» и передаются местному серверу, как если бы они исходили от местного X-клиента (так оно и есть: этот клиент – ssh).
XFree86. Модули и расширения
Наиболее распространенная версия реализации X11R6 называется XFree86. Эта графическая подсистема изначально проектировалась как реализация X11R5 для машин архитектуры i386 – самых распространенных на сегодня персональных компьютеров. Главная особенность этой архитектуры – бесчисленное множество устройств графического вывода (так называемых видеокарт) и непрестанное нарушение их разработчиками всех мыслимых стандартов. Поэтому главной задачей создателей XFree86 было организовать гибкую структуру компоновки и настройки X-сервера в соответствии с подвернувшимся под руку устройством графического вывода, а заодно и ввода, потому что клавиатур, мышей и заменяющих их устройств на свете тоже немало. Сегодня XFree86 существует для многих архитектур и многих операционных систем.
Требование гибкости привело к тому, что XFree86 стала совсем уже похожа на ОС. Сам сервер XFree86 играет роль ядра. Запускаясь, сервер подгружает драйверы – специальные компоненты, работающие с выбранной видеокартой, и модули – компоненты, расширяющие функциональные возможности сервера. Драйверы и модули загружаются не все: X-сервер работает с одной видеокартой и может делать только то, о чем его попросили. Есть весьма полезные расширения, вроде Xinput (работа с устройствами ввода), glx (высокоуровневые функции трехмерной графики) или freetype (поддержка шрифтов TrueType), а есть экзотические, которые иногда могут понадобиться, например RECORD, позволяющее записывать, а после – «проигрывать» все происходящие с сервером события.
Расширения называются так еще и потому, что их возможности расширяют сам протокол X11R6. Вместо того чтобы изменять протокол всякий раз, когда в голову придет очередная еще не реализованная в нем возможность, создатели X11 предусмотрели стандартный способ дополнения этого протокола. При этом X-клиент, желающий воспользоваться определенным расширением, всегда может спросить у X-сервера, поддерживается ли оно, и действовать по обстановке.
В X11/XFree86 появились даже собственные демоны! С одним из них мы уже знакомы – это xdm, занимающийся аутентификацией. Подобно демону, он постоянно находится в памяти, пока пользователь неактивен, и, подобно демону, обладает многими привилегиями по сравнению с пользовательскими процессами. Настоящий демон (притом сетевой) – xfs, сервер шрифтов для X11. Он особенно удобен для X-терминалов и вообще для централизованной настройки шрифтов. Смысл сервера шрифтов в том, чтобы X-сервер брал необходимые ему шрифты не из файлов на собственной машине (они еще и места занимают немало), а по сети, обращаясь к единственному на всю локальную сеть xfs.
Как полагается, в XFree86 есть и утилиты, причем и системные – для настройки самого X-сервера, и пользовательские – для решения мелких, но популярных задач. Пример системной утилиты – xvidtune, с помощью которой можно подобрать наилучший режим работы сервера с имеющимися видеокартой и монитором, или xf86cfg – утилита начальной настройки всей XFree86. Конечно, пользоваться системными утилитами должен только человек, разбирающийся в устройстве XFree86. Многие дистрибутивы UNIX включают в себя собственные полуавтоматические утилиты настройки X11. Эти утилиты имеют процедурную природу, и ими можно создать более или менее подходящий профиль, не вникая в тонкости. Для того чтобы работать с XFree86 как с проективной системой, рекомендуется изучить руководства по X, Xserver, XFree86 и, конечно, по структуре настроечного файла XF86Config.
Пользовательские утилиты либо повторяют функциональность утилит UNIX (xkill, xman), либо привязаны к определенным сторонам X-сервера: выдают информацию об окнах (xwininfo и ей подобные), настраивают сервер (xset), показывают шрифты (xfd и xfontsel) и т. п. Есть также простейшие программы, типичные для графической среды, вроде xcalc, xedit, xmag и других. Ими вполне можно пользоваться, но стоит иметь в виду, что графическая подсистема в UNIX рассчитана на то, что решения пользовательских задач для нее будет создавать все прогрессивное человечество. Поэтому самые сложные и многофункциональные программы не входят в состав XFree86, это пакеты UNIX.
Как и полагается проективной системе, UNIX включает богатый инструментарий для работы с X11: библиотеки процедур, решающие различные классы задач, специализированные языки программирования, системы разработки. Так что все прогрессивное человечество не обделило X11 вниманием: существует масса программных продуктов, использующих X11R6. Так, в дистрибутиве FreeBSD 5.2.1 их более 600 (при этом официально работающих FreeBSD пакетов под X11 – более 4000), а в дистрибутиве ALT Linux Master 2.2 – более 450 одних только пакетов, использующих X11 напрямую.

X-приложения

Программный продукт, использующий X11, называется приложением (application, другое значение – «применение»). Если считать, что сами графические возможности уже реализованы X-сервером и библиотеками, то программа и в самом деле окажется приложением к системе, и вся ее заслуга будет состоять только в том, что она применила эти возможности для решения своей задачи.

DISPLAY

При запуске X-приложение проверяет переменную окружения DISPLAY. В этой переменной указано, к какому именно X-серверу оно обратится с запросами. Формат DISPLAY прост: способ_доступа:номер_сервера.номер_экрана. Под способом доступа может подразумеваться сеть (тогда используется сетевой адрес машины с X-сервером) или какой-нибудь еще механизм, принятый в конкретной системе. Если не написать ничего, будет выбран способ по умолчанию. Номер сервера нужен для того, чтобы различать X-серверы, запущенные на одном компьютере. В Linux или FreeBSD можно запустить несколько XFree86 и переключаться между ними, как между виртуальными консолями – с помощью Ctrl+Alt+F1, Ctrl+Alt+F2 и т. д. В системе может быть несколько виртуальных серверов (например, sshd). Все они должны иметь разные номера. Наконец, один сервер может работать с несколькими экранами – и физически (есть видеокарты с выходами на несколько мониторов), и виртуально (вот тут уж никаких ограничений нет). Правда, это бывает нечасто, и номер экрана тоже можно не писать.
Чаще всего переменная DISPLAY равна ":0": способ доступа – по умолчанию, нулевой сервер, нулевой экран. Если вы воспользовались ssh -X, то увидите в этой переменной что-нибудь наподобие "myhost.mydomain.net:10.0:" доступ по IP-адресу, десятый сервер на удаленной машине и нулевой экран.

Окновод

Мы уже упоминали, что X-сервер не занимается логикой работы с окнами (за исключением смены фокуса). X-сервер, к которому присоединено ровно два клиента, чьи окна перекрываются, представляет собой душераздирающее зрелище: на черно-белом, в мелкую крапинку, фоне два черно-белых окна друг на друге, и их ни растащить по углам, ни сжать нельзя. X-сервер умеет очень ловко манипулировать окошками, но сам никогда ничего не делает, дожидается команды от пользовательской программы. А какой программе захочется самостоятельно отслеживать перекрытие окон, фокус, заниматься изменением размера, перемещением и тому подобным? Ведь основная задача программы может быть совсем другой...
Ответ очевиден: этим должна заниматься программа, основная задача которой состоит в том, чтобы отслеживать перекрытие, изменять размер, двигать, превращать в иконку и т. д. По совместительству эта же программа будет рисовать при окнах разные украшения: рамочки, заголовки, кнопки и меню управления – словом, делать все, что потребно для организации логики управления окнами. Этот X-клиент называется менеджером окон (window manager) или окноводом.
Окноводом может стать каждый! Правда, для этого нужно многое уметь: кроме перечисленного выше, еще надо обрабатывать практически все события, передаваемые от устройств ввода, и многочисленные «подсказки» от приложений относительно того, какими они хотят видеть собственные окна. Разнообразных менеджеров окон на свете множество: от самых простых (рамочка вокруг окна позволяет двигать его, изменять размер и поднимать из глубины) до весьма изысканных (виртуальные экраны, движущиеся полупрозрачные меню, панели инструментов, причудливой формы украшения на окнах; сами окна ползают по экранам, кувыркаются, растворяются, как утренний туман... чего только не придумают).
Выбор окновода на свой вкус – занятие непростое. Мы советуем просто соблюдать меру, сообразуясь с тем, для чего используется оконная система: обилие декораций отвлекает от работы (а если они вдобавок шевелятся?), а минимализм ее усложняет. Имейте в виду, что чем причудливее и многообразнее возможности окновода, тем труднее будет его полностью настроить именно под себя. Скорее всего, вы просто согласитесь пользоваться уже настроенными – общеупотребительными – возможностями, не доводя их до совершенства. Впрочем, современному человеку, приученному к готовому платью и еде с конвейера, не привыкать...

XTerm

С графикой или без, основным интерфейсом управления UNIX была и остается командная строка. X11, предлагая иной способ взаимодействия с компьютером, не должна лишать пользователя возможности работать с самой системой испытанным и эффективным методом – через терминал.
Задача предоставить пользователю X11 командную строку решается довольно легко. Нужно завести X-приложение, окно которого работает аналогично окну терминала: передает символьную информацию от пользователя системе и обратно. Такое приложение будет задействовать псевдотерминал примерно так же, как это делает утилита screen (см. лекцию 8): обмениваться символами с его pty-стороной, а к другой стороне, ttyp, можно подключить пользовательский командный интерпретатор.
Общее название таких программ – эмулятор терминала для X11, XTerm. Не следует путать программу XTerm (или аналогичные ей konsole, rxvt, gterm и т. п.) со способом организации рабочей станции (так называемый «X-терминал»): термины эти созвучны, но относятся к разным областям знаний. Нередко бывает, что на экране X-терминала (компьютера) есть окно терминала X11 (программы XTerm). XTerm передает сигналы как настоящий терминал, имеет богатый набор управляющих последовательностей (унаследованный от устройства «DEC VT102/VT220»), а вдобавок позволяет воспользоваться всеми преимуществами графической среды: выбрать шрифт, запомнить текст на экране (и даже тот, что только что исчез с него), поменять заголовок и название иконки и многое другое.
Кстати сказать, возможность копирования текста при помощи мыши – свойство не только XTerm. На самом деле любое окно, зарегистрированное в X11 как текстовое, позволяет отметить (при постоянно нажатой первой кнопке мыши или последовательными нажатиями первой и третьей) часть текста. Выделенный текст можно немедленно вставить в любое окно текстового ввода нажатием второй кнопки. Утилита xcutsel предоставляет возможность работы с буфером обмена (cutbuffer), в котором текст может храниться сколь угодно долго.

Сеанс работы с X11

Для работы в X11 пользователю необходимо запустить сразу несколько приложений. В самом деле, кроме окновода нужен хотя бы один XTerm, а сверх того – разные мелкие программки, вроде индикатора загрузки системы 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, кроме последнего, запускать в фоне, чтобы командный интерпретатор не дожидался окончания их работы. Последней программой в стартовом сценарии может быть XTerm, как это сделано в стандартном xinitrc, или менеджер окон. Для завершения XTerm (а с ним и всего сеанса работы X11) достаточно послать ^D запущенному в нем shell, а окновод обычно имеет какую-нибудь кнопочку или меню Exit. Программа, с завершением которой заканчивается сеанс X11, называется лидером сеанса (session leader).
На самом деле X-сервер необходимо перезапускать и при использовании xdm. Несмотря на то что пользователи взаимодействуют только с X-сервером, не задействуя виртуальные консоли, было бы неудобно и небезопасно сохранять какие бы то ни было настройки, сделанные одним пользователем ко времени работы другого. Самое неприятное – это так называемый «клавиатурный вор» (keyboard grabber), программа, притворяющаяся окноводом, для того лишь, чтобы запоминать все, что пользователь ввел с клавиатуры (злоумышленников интересуют, как правило, пароли). Нарушения принципов безопасности легко избежать, если не использовать xhost (авторизацию на основе адреса) и не доверять X-серверу, запущенному не при вас.

Инструментарий X11

Приложения X11 создаются с помощью разнообразных готовых инструментов. Большая их часть разрабатывается независимыми авторами по всему миру (это общее свойство свободного ПО), но библиотека самого низкого уровня, X Lib, и несколько более высокоуровневых с давних пор включаются в основной дистрибутив X11. Из них наиболее примечательна X Toolkit (Xt), организующая из стандартных окон X11 так называемые оконные примитивы (их собственное имя – widgets – сокращение от window gadgets, «оконные безделушки»). Xlib задает логику работы X-приложения, а совместно с Xt организует ресурсный подход к построению программ для X11.
Дело в том, что каждый объект 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 не запускалась ни разу (в том числе и в стартовом сценарии), запрос приложения будет направлен не в таблицу сервера, а непосредственно в файл ресурсов .Xdefaults, лежащий в домашнем каталоге. В этом случае для изменения настроек не надо запускать 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.

Рабочий стол

С появлением универсальных высокоуровневых инструментариев стала обретать плоть идея воплощения метафоры рабочего стола, впервые реализованная в системах семейства MacOS. Смысл рабочего стола в том, чтобы предложить принципиально иной способ взаимодействия человека и компьютера – способ, основанный на манипуляции единичными именованными объектами. Каталоги превращаются в «папки с документами», причем каждый тип документов можно «открыть» с помощью специального «документатора». Программы превращаются в эдакие вместилища абстрактных функциональностей: «Internet», «Почта», «Видео» и т. п. рабочий стол особенно необходим человеку, чья область деятельности далека от компьютерного дела, для кого он – не вычислительная машина, а инструмент решения отдельных – типовых и чаще всего непрофильных задач.
Обилие кавычек в приведенном примере наводит на мысль, что внешний вид рабочего стола имеет не много общего с внутренним его устройством и что за этой метафорой должна стоять мощная и хорошо проработанная легенда (см. лекцию 3). На сегодня самой хорошей и непротиворечивой легендой, пожалуй, обладает вышеупомянутый MacOS. Нелишне заметить, что с выходом MacOS X системы этой ветки – исключительно коммерческие – используют для реализации легенды и прочих процедурных ухищрений... ветку BSD, со всеми утилитами, демонами и т. п.! Видимо, среди разработчиков MacOS X нашлись любители скрещивания; эта часть системы даже называется «Дарвин», см. http://developer.apple.com/darwin. Таким образом, рабочий стол сам по себе – совершенная процедурная система, и говорить здесь было бы не о чем, если бы не два важных обстоятельства.
Во-первых, компьютер так уверенно вошел «в каждый дом», что давно уже стал бытовым прибором для игр, чтения электронной почты, просмотра WWW, а в последнее время – музыкальным центром и видеопроигрывателем. Грешно требовать от садящейся за клавиатуру домохозяйки строгого следования принципам проективной системы. Лучше дать им в руки красивую и сравнительно безопасную игрушку, которая способна удовлетворять их бытовые нужды. Таких игрушек для X11 несколько. Две мощные среды «офисного» плана – KDE (основанное на Qt переосмысление коммерческой среды CDE) и Gnome (основанная на GTK) – содержат все необходимое для работы (включая собственные офисные приложения и средства просмотра WWW). Или, например, среда XFCE (основанная также на GTK) – крепко сбитый минималистский вариант CDE, простой в применении, как выдвижной ящик.
Что касается именно офисных приложений, то тут лидером на рынке свободно распространяемых программ является, безусловно, OpenOffice.org («Открытый офис»). Про него мы много говорить не будем: как и подобает офисным приложениям, интерфейс его компонентов полностью процедурен, а внутренности интересны лишь специалистам. Этот пакет существует для многочисленных систем (включая Windows), он содержит все основные офисные программы и безупречно работает с популярными форматами файлов .doc , .xls, .ppt и прочими.
Во-вторых, очень трудно провести границу, где заканчиваются обязанности окновода и начинаются манипуляции рабочего стола. Видимо, менеджер окон делается средой рабочего стола, когда в народе начинают писать пользовательские приложения с использованием его особых свойств и его библиотек. В тяжелых весовых категориях выступают и FVWM2 (множество функций), и Enlightenment (настоящая игрушка), и WindowMaker, и некоторые другие. Человеку, проводящему рабочее время за экраном компьютера, важен комфорт на рабочем месте, поэтому всякая мелочь или ее отсутствие может иметь решающее значение при выборе того или иного окновода.
С этой точки зрения, чем больше система будет уметь, тем лучше для профессионала – лишь бы в вопросах взаимодействия с ней соблюдались проективные принципы:

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

Сравнительная таблица командных интерпретаторов


Систаксис языка

sh, Bourne

csh, C

ksh, Bourne*

posix, sh, Bourne*

(d)ash, Bourne*

bash, Bourne#

tcsh, C#

zsh, Bourne#

Программирование

+

+

+

+

+

+

+

+

Подстановка

+

+

+

+

+

*

*

#

Модификаторы поведения

-

-

-

-

-

+

+

#

Арифметические операции

-

+

+

+

+

+

+

#

Массивы

-

+

-

-

-

+

+

+

Управление заданиями

-

+

+

+

+

+

+

+

Редактор командной строки

unix

ed

emcs/vi

emcs

emcs

rdline

tcshcle

zle

Обработка строк-подсказок

-

-

-

-

-

+

#

#

Работа с историей команд

-

ed

+

+

+

#

#

#

Псевдонимы

-

+

+

+

+

+

+

+

Переназначение клавиш

-

-

dumb

+

+

rdline

progr

progr

Достраивание

-

file

file

-

-

+

+

progr

Модульность

-

-

-

-

-

-

-

+

Пояснения к таблице.


-

отсутствует

+

реализовано

*

реализовано, доработано и улучшено

#

значительно доработано, обладает большими возможностями

unix

реактирование средствами терминальной линии Unix

ed

построчное редактирование в стиле ed

vi

экранное редактирование в стиле vi

emcs

экранное редактирование в стиле emacs

rdline

основано на возможностях библиотеки readline (расширенный стиль emacs + vi)

tcshcle

собственная библиотека tcsh: tcshell command line editor (расширенный стиль emacs + vi)

zle

собственная библиотека zsh: Z line editor (расширенный стиль emacs + vi)

dumb

переназначение в ksh очень урезано и организовано с помощью псевдонимов специального вида

progr

программируется средствами языка

file

достраивание только имён файлов

 

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