Основной протокол X Window System

Логотип системы X Window

Основной протокол X Window System — базовый протокол X Window System , сетевой оконной системы для растровых дисплеев, используемой для создания графических пользовательских интерфейсов в Unix , Unix-подобных и других операционных системах . Система X Window основана на модели клиент-сервер : один сервер управляет оборудованием ввода/вывода , таким как экран , клавиатура и мышь ; все прикладные программы действуют как клиенты , взаимодействуя с пользователем и другими клиентами через сервер. Это взаимодействие регулируется основным протоколом X Window System. Существуют и другие протоколы, связанные с X Window System, либо построенные на основе основного протокола X Window System, либо в виде отдельных протоколов.

отправляются только четыре типа пакетов В основном протоколе X Window System по сети асинхронно : запросы, ответы, события и ошибки. Запросы отправляются клиентом на сервер, чтобы попросить его выполнить некоторую операцию (например, создать новое окно) и отправить обратно данные, которые он хранит. Ответы отправляются сервером для предоставления таких данных. События отправляются сервером для уведомления клиентов об активности пользователей или других событиях, которые их интересуют. Ошибки — это пакеты, отправляемые сервером для уведомления клиента об ошибках, произошедших во время обработки его запросов. Запросы могут генерировать ответы, события и ошибки; кроме этого, протокол не устанавливает определенного порядка отправки пакетов по сети. Существуют некоторые расширения основного протокола, каждое из которых имеет свои собственные запросы, ответы, события и ошибки.

X зародился в Массачусетском технологическом институте в 1984 году (нынешний релиз X11 появился в сентябре 1987 года). Его создатели Боб Шейфлер и Джим Геттис в качестве одного из первых принципов заложили, что его основной протокол заключается в «создании механизма, а не политики». В результате основной протокол не определяет взаимодействие между клиентами, а также между клиентом и пользователем. Эти взаимодействия являются предметом отдельных спецификаций. такие как ICCCM и спецификации freedesktop.org , и обычно применяются автоматически с использованием заданного набора виджетов .

Обзор

В этом примере X-сервер принимает вводимые данные с клавиатуры и мыши и отображает их на экране. и Веб-браузер эмулятор терминала запускаются на рабочей станции пользователя, а эмулятор терминала запускается на удаленном сервере, но под управлением компьютера пользователя. Обратите внимание, что удаленное приложение работает так же, как и локально.

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

Пример взаимодействия клиента и сервера.

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

1. Запрос: клиент запрашивает информацию у сервера или просит его выполнить действие.
2. Ответ: Сервер отвечает на запрос. Не на все запросы генерируются ответы.
3. Событие: сервер информирует клиента о событии, таком как ввод с клавиатуры или мыши, перемещение, изменение размера или раскрытие окна и т. д.
4. Ошибка: сервер отправляет пакет ошибки, если запрос недействителен. Поскольку запросы ставятся в очередь, пакеты ошибок, сгенерированные запросом, могут быть отправлены не сразу.

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

Пакеты запросов последовательно нумеруются сервером по мере их получения: первый запрос от клиента имеет номер 1, второй 2 и т. д. Младшие 16 бит последовательного номера запроса включаются в ответ и ошибку. пакеты, сгенерированные запросом, если таковые имеются. Они также включаются в пакеты событий для указания порядкового номера запроса, который сервер в данный момент обрабатывает или только что завершил обработку.

Окна

То, что обычно называют окном в большинстве графических пользовательских интерфейсов, называется окном верхнего уровня в системе X Window . Термин «окно» также используется для обозначения окон, находящихся внутри другого окна, то есть подокна родительского окна . Графические элементы, такие как кнопки , меню , значки и т. д., можно реализовать с помощью подокна.

Возможное размещение некоторых окон: 1 — корневое окно, занимающее весь экран; 2 и 3 — окна верхнего уровня; 4 и 5 являются подокнами окна 2. Части окна, находящиеся за пределами родительского окна, не видны.

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

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

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

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

Анатомия окна FVWM . Белая область — это окно, созданное и видимое клиентским приложением.

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

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

Растровые изображения и рисунки

Растровое изображение — это область памяти, которую можно использовать для рисования. В отличие от окон, растровые изображения не отображаются на экране автоматически. Однако содержимое растрового изображения (или его часть) можно перенести в окно и наоборот. Это позволяет использовать такие методы, как двойная буферизация . Большинство графических операций, которые можно выполнять в окнах, также можно выполнять и с растровыми изображениями.

Windows и растровые изображения называются drawables , а данные их содержимого хранятся на сервере. Однако клиент может запросить передачу содержимого объекта рисования с сервера клиенту или наоборот.

Графические контексты и шрифты

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

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

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

The xfontsel Программа позволяет пользователю просматривать глифы шрифта.

Имена шрифтов представляют собой произвольные строки на уровне основного протокола X Window. Соглашения описании логических шрифтов X об укажите, как следует называть шрифты в соответствии с их атрибутами. Эти соглашения также определяют значения дополнительных свойств, которые можно прикрепить к шрифтам.

The xlsfonts программа печатает список шрифтов, хранящихся на сервере. xfontsel Программа показывает глифы шрифтов и позволяет пользователю выбрать имя шрифта для вставки его в другое окно.

Использование серверных шрифтов в настоящее время считается устаревшим в пользу клиентских шрифтов. Такие шрифты отображаются клиентом, а не сервером, при поддержке библиотек Xft или cairo и расширения XRender . В базовом протоколе не приводятся спецификации клиентских шрифтов.

Ресурсы и идентификаторы

Все данные об окнах, растровых изображениях, шрифтах и ​​т. д. хранятся на сервере. Клиент знает идентификаторы этих объектов — целые числа, которые он использует в качестве имён при взаимодействии с сервером. Например, если клиент желает создать окно, он запрашивает сервер создать окно с заданным идентификатором. Идентификатор может позже использоваться клиентом для запроса, например, строки, которая будет нарисована в окне. Следующие объекты находятся на сервере и известны клиенту по числовому идентификатору:

• Window
• Pixmap
• Font
• Colormap (таблица цветов, описана ниже)
• Graphic context

Эти объекты называются ресурсами . Когда клиент запрашивает создание одного такого ресурса, он также указывает для него идентификатор. Например, для создания нового окна клиент указывает как атрибуты окна (родительский, ширина, высота и т. д.), так и идентификатор, который нужно связать с окном.

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

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

Идентификаторы уникальны для сервера, а не только для клиента; например, никакие два окна не имеют одинаковый идентификатор, даже если они созданы двумя разными клиентами. Клиент может получить доступ к любому объекту по его идентификатору. В частности, он также может получить доступ к ресурсам, созданным любым другим клиентом, даже если их идентификаторы находятся за пределами набора идентификаторов, которые он может создать.

В результате два клиента, подключенные к одному и тому же серверу, могут использовать один и тот же идентификатор для обращения к одному и тому же ресурсу. Например, если клиент создает окно идентификатора 0x1e00021 и передает этот номер 0x1e00021 другому приложению (любыми доступными способами, например, сохранив этот номер в файле, который также доступен другому приложению), это другое приложение может работать в том же окне. Эта возможность, например, используется версией Ghostview для X Window : эта программа создает подокно, сохраняя его идентификатор в переменной среды , и вызывает Ghostscript ; эта программа рисует содержимое файла PostScript для отображения в этом окне.

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

События

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

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

Клиент может запросить сервер отправить событие другому клиенту; это используется для связи между клиентами. Такое событие генерируется, например, когда клиент запрашивает выделенный в данный момент текст: это событие отправляется клиенту, который в данный момент обрабатывает окно, содержащее выделение.

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

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

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

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

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

The xev программа показывает события относительно окна. В частности, xev -id WID запрашивает все возможные события относительно окна идентификатора WID и печатает их.

Пример

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

1. Клиент открывает соединение с сервером и отправляет исходный пакет, указывая используемый им порядок байтов.
2. Сервер принимает соединение (в этом примере авторизация не используется), отправляя соответствующий пакет, который содержит другую информацию, такую ​​как идентификатор корневого окна (например, 0x0000002b) и какие идентификаторы может создать клиент.
3. Клиент запрашивает создание графического контекста по умолчанию с идентификатором 0x00200000 (этот запрос, как и другие запросы этого примера, не генерирует ответы от сервера)
4. Клиент запрашивает сервер создать окно верхнего уровня (то есть указывает родительское окно как корневое). 0x0000002b) с идентификатором 0x00200001, размер 200x200, позиция (10,10) и т. д.
5. Клиент запрашивает изменение атрибутов окна 0x00200001, указав, что он заинтересован в получении Expose и KeyPress события.
6. Клиент запрашивает окно 0x00200001 быть нанесен на карту (показано на экране)
7. Когда окно становится видимым и его содержимое необходимо отрисовать, сервер отправляет клиенту сообщение Expose событие
8. В ответ на это событие клиент запрашивает отрисовку прямоугольника, отправляя PolyFillRectangle запрос с окном 0x00200001 и графический контекст 0x00200000

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

1. Сервер отправляет еще один Expose событие, сообщающее клиенту, что окно нужно отрисовать еще раз
2. Клиент перерисовывает окно, отправляя PolyFillRectangle запрос

Если клавиша нажата:

1. Сервер отправляет KeyPress событие для клиента, чтобы уведомить его о том, что пользователь нажал клавишу
2. Клиент реагирует соответствующим образом (в данном случае завершается)

Цвета

На уровне протокола цвет представлен 32-битным целым числом без знака, называемым значением пикселя . Следующие элементы влияют на представление цветов:

1. цвета глубина
2. цветовая карта , которая представляет собой таблицу, содержащую значения интенсивности красного, зеленого и синего.
3. визуальный тип , который определяет, как таблица используется для представления цветов.

В простейшем случае цветовая карта представляет собой таблицу, содержащую тройку RGB в каждой строке. Значение пикселя x представляет цвет, содержащийся в x-я строка таблицы. Если клиент может изменить записи в цветовой карте, это представление идентифицируется PseudoColor визуальный класс . Визуальный класс StaticColor аналогично, но клиент не может изменять записи в цветовой карте.

Всего существует шесть возможных визуальных классов, каждый из которых определяет свой способ представления тройки RGB со значением пикселя. PseudoColor и StaticColor два. Еще два GrayScale и StaticGray, которые отличаются тем, что отображают только оттенки серого.

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

1. значение пикселя рассматривается как последовательность битов
2. эта последовательность разбита на три части
3. каждый из этих трех фрагментов битов рассматривается как целое число и используется как индекс для поиска значения в каждой из трех отдельных таблиц.

Этот механизм требует, чтобы цветовая карта состояла из трех отдельных таблиц, по одной для каждого основного цвета . Результатом преобразования по-прежнему является тройка значений интенсивности. Визуальные классы, использующие это представление, — это DirectColor и TrueColor те, которые различаются тем, может ли клиент изменять цветовые карты или нет.

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

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

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

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

Создание цветовых карт регулируется конвенцией ICCCM . Стандартные карты цветов регулируются ICCCM и спецификацией Xlib .

Частью системы цвета X является система управления цветом X (xcms). Эта система была представлена ​​в X11R6 Release 5 в 1991 году. Эта система состоит из нескольких дополнительных функций в xlib, найденных в серии функций Xcms*. Эта система определяет аппаратно-независимые цветовые схемы, которые можно преобразовать в аппаратно-зависимые системы RGB. Система состоит из функций xlib Xcms*, а также Соглашения о характеристиках цвета устройства X (XDCCC), которое описывает, как преобразовать различные аппаратно-независимые цветовые системы в аппаратно-зависимые цветовые системы RGB. Эта система поддерживает CIEXYZ , xyY , CIELUV и CIELAB , а также цветовые системы TekHVC . [1] , [2]

Атомы

Атомы — это 32-битные целые числа, представляющие строки . Разработчики протокола ввели атомы, поскольку они представляют строки короткого фиксированного размера: хотя строка может быть произвольной длины, атом всегда представляет собой 32-битное целое число. Краткость Atom была использована путем обязательного использования их в пакетах, которые, вероятно, будут отправляться много раз с одними и теми же строками; это приводит к более эффективному использованию сети. Фиксированный размер атомов был использован путем указания фиксированного размера для событий, а именно 32 байта: пакеты фиксированного размера могут содержать атомы, но не могут содержать длинные строки.

Точнее, атомы — это идентификаторы строк, хранящихся на сервере. Они похожи на идентификаторы ресурсов (Windows, Pixmaps и т. д.), но отличаются от них по двум причинам. Во-первых, идентификаторы атомов выбираются сервером, а не клиентом. Другими словами, когда клиент запрашивает создание нового атома, он отправляет серверу только строку, которую нужно сохранить, а не ее идентификатор; этот идентификатор выбирается сервером и отправляется обратно клиенту в качестве ответа. Второе важное различие между ресурсами и атомами заключается в том, что атомы не связаны с клиентами. После создания атом сохраняется до тех пор, пока сервер не завершит работу или не перезагрузится (это не поведение ресурсов по умолчанию).

Атомы являются идентификаторами и поэтому уникальны. Однако атом и идентификатор ресурса могут совпадать. Строка, связанная с атомом, называется именем атома . Имя атома не может быть изменено после создания, и никакие два атома не могут иметь одинаковое имя. В результате для обозначения атома обычно используется имя атома: «атом ABCDболее точно означает «атом, чья связанная строка равна ABCD». или «атом, имя которого ABCD». Клиент может запросить создание нового атома и может запросить атом (идентификатор) данной строки. Некоторые атомы предопределены (создаются сервером с заданным идентификатором и строкой).

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

Список всех атомов, находящихся на сервере, можно распечатать с помощью программы xlsatoms. В частности, эта программа печатает каждый атом (идентификатор, то есть число) с его именем (связанной с ним строкой).

Характеристики

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

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

Имя, тип и значение свойства являются строками; точнее, это атомы, то есть строки, хранящиеся на сервере и доступные клиентам через идентификаторы. Клиентское приложение может получить доступ к заданному свойству, используя идентификатор атома, содержащий имя свойства.

Свойства в основном используются для межклиентского общения. Например, свойство с именем WM_NAME (свойство, названное атомом, связанная строка которого равна "WM_NAME") используется для хранения названий окон. Менеджеры окон обычно читают это свойство, чтобы отображать имена окон в строке заголовка.

Некоторые типы межклиентского взаимодействия используют свойства корневого окна. Например, согласно спецификации оконного менеджера freedesktop , Оконные менеджеры должны хранить идентификатор текущего активного окна в свойстве с именем _NET_ACTIVE_WINDOW корневого окна. Ресурсы X , содержащие параметры программ, также хранятся в свойствах корневого окна; таким образом все клиенты смогут получить к ним доступ, даже если они работают на разных компьютерах.

The xprop программа печатает свойства данного окна; xprop -root печатает имя, тип и значение каждого свойства корневого окна.

Сопоставления

Этот ключ всегда генерирует один и тот же код ключа , но символы /, 7, и { связаны с тремя разными символами клавиш .

В системе X Window каждому отдельному физическому ключу присвоен номер в диапазоне 8–255, называемый его кодом ключа . Код ключа идентифицирует только ключ, а не конкретный символ или термин (например, «Page Up») среди тех, которые могут быть напечатаны на ключе. Вместо этого каждый из этих символов или терминов идентифицируется ключевым символом . Хотя код клавиши зависит только от фактической нажатой клавиши, символ клавиши может зависеть, например, от того, была ли также нажата клавиша Shift или другой модификатор .

При нажатии или отпускании клавиши сервер отправляет события типа KeyPress или KeyRelease соответствующим клиентам. Эти события содержат:

1. код нажатой клавиши
2. текущее состояние модификаторов (Shift, Control и т.д.) и кнопок мыши

Перевод с keycode на keysym.

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

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

Модификатор — это клавиша, при нажатии которой изменяется интерпретация других клавиш. Распространенным модификатором является клавиша Shift : когда клавиша, которая обычно создает строчную букву «а», нажимается вместе с клавишей Shift, она создает прописную букву «А». Другими распространенными модификаторами являются «Control», «Alt» и «Meta».

X-сервер работает максимум с восемью модификаторами. Однако каждый модификатор может быть связан с более чем одной клавишей. Это необходимо, поскольку многие клавиатуры имеют дублированные клавиши для некоторых модификаторов. Например, на многих клавиатурах есть две клавиши «Shift» (одна слева и одна справа). Эти две клавиши при нажатии создают два разных кода клавиш, но X-сервер связывает их с модификатором «Shift».

Для каждого из восьми модификаторов X-сервер хранит список кодов клавиш, которые он считает этим модификатором. Например, если список первого модификатора (модификатор «Shift») содержит код клавиши 0x37, затем ключ, создающий код ключа 0x37 X-сервер считается клавишей Shift.

Списки сопоставлений модификаторов поддерживаются X-сервером, но могут быть изменены каждым клиентом. Например, клиент может запросить клавиши «F1 добавление » в список модификаторов «Shift». С этого момента эта клавиша ведет себя как еще один модификатор сдвига. Однако код клавиши, соответствующий F1, по-прежнему генерируется при нажатии этой клавиши. В результате F1 работает так же, как и раньше (например, при ее нажатии может открыться окно справки), но также работает как клавиша Shift (нажатие «a» в текстовом редакторе при нажатой клавише F1 добавляет «A» к текущему тексту).

X-сервер поддерживает и использует сопоставление модификаторов для кнопок мыши. Однако кнопки можно только переставлять местами . Это в основном полезно для замены крайней левой и крайней правой кнопки для пользователей -левшей .

The xmodmap программа показывает и изменяет сопоставления клавиш, модификаторов и кнопок мыши.

захваты

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

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

• активно: захват происходит немедленно
• пассивный: захват происходит только при нажатии заранее указанной клавиши или кнопки мыши и прекращается при ее отпускании

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

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

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

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

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

Другой

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

Расширения

позволяет Расширение формы oclock создавать круглое окно.

Основной протокол X Window был разработан с возможностью расширения. Базовый протокол определяет механизм запроса доступных расширений и способы формирования пакетов запросов расширений, событий и ошибок.

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

Авторизация

Основная статья: Авторизация X Window

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

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

Xlib и другие клиентские библиотеки

Основная статья: Xlib

Большинство клиентских программ взаимодействуют с сервером через клиентскую библиотеку Xlib . В частности, большинство клиентов используют такие библиотеки, как Xaw , Motif , GTK+ или Qt , которые, в свою очередь, используют Xlib для взаимодействия с сервером. Использование Xlib имеет следующие эффекты:

1. Xlib делает клиент синхронным относительно ответов и событий:
   1. функции Xlib, отправляющие запросы, блокируются до тех пор, пока не будут получены соответствующие ответы, если таковые ожидаются; другими словами, клиент X Window, не использующий Xlib, может отправить запрос на сервер, а затем выполнять другие операции, ожидая ответа, но клиент, использующий Xlib, может только вызвать функцию Xlib, которая отправляет запрос и ожидает ответа. тем самым блокируя клиента во время ожидания ответа (если клиент не запускает новый поток перед вызовом функции);
   2. в то время как сервер отправляет события асинхронно , Xlib сохраняет события, полученные клиентом, в очереди ; клиентская программа может получить к ним доступ только путем явного вызова функций библиотеки X11; другими словами, клиент вынужден блокироваться или находиться в режиме ожидания, если ожидает события.
2. Xlib не отправляет запросы на сервер сразу, а сохраняет их в очереди, называемой выходным буфером ; запросы в выходном буфере фактически отправляются, когда:
   1. программа явно запрашивает это, вызывая библиотечную функцию, например XFlush;
   2. программа вызывает функцию, которая в результате выдает что-то, требующее ответа от сервера, например: XGetWindowAttributes;
   3. программа запрашивает событие в очереди событий (например, вызывая XNextEvent) и блоки вызовов (например, XNextEvent блокируется, если очередь пуста.)

Библиотеки более высокого уровня, такие как Xt (которые, в свою очередь, используются Xaw и Motif ), позволяют клиентской программе указывать функции обратного вызова , связанные с некоторыми событиями; библиотека берет на себя опрос очереди событий и вызов соответствующей функции, когда это необходимо; некоторые события, например, указывающие на необходимость перерисовки окна, обрабатываются внутри Xt.

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

Неуказанные части

Основной протокол X Window System не требует межклиентской связи и не определяет, как окна используются для формирования визуальных элементов, которые являются общими для графических пользовательских интерфейсов ( кнопок , меню и т. д.). Элементы графического пользовательского интерфейса определяются клиентскими библиотеками, реализующими наборы инструментов виджетов . Межклиентская связь регулируется другими стандартами, такими как ICCCM и спецификациями freedesktop .

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

Управление сеансами

Еще одна проблема, где межклиентское общение в некоторой степени актуально, — это управление сеансами .

То, как начинается сеанс пользователя, — это еще одна проблема, не охваченная основным протоколом. Обычно это делается автоматически менеджером дисплея X. Однако пользователь также может запустить сеанс вручную, запустив программы xinit или startx .

См. также

• Протоколы и архитектура X Window System
• Xlib
• Внутренности
• Xnee можно использовать для анализа протокола X Window System.

Внешние ссылки

• X.Org Foundation (официальная домашняя страница) — зеркало с доменным именем freedesktop.org.
• Внутреннее устройство X Window System
• Страницы Кентона Ли о X Window и Motif
• Протокол X Window System, версия 11 (текущий выпуск)