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

Логотип X Window System

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

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

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

Обзор

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

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

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

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

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

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

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

Windows

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

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

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

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

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

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

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

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

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

Пиксельные карты и чертежи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

События

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

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

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

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

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

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

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

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

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 ресурсы , которые содержат параметры программ, которые также хранятся в свойствах корневого окна; таким образом, все клиенты могут получить к ним доступ, даже если они работают на разных компьютерах.

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

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

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

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

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

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

Перевод с ключевого кода на keycode.

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

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

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

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

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

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

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

В xmodmap программе выставки и изменения отображения ключ, модификаторов и кнопок мыши.

Захватывает

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

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

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

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

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

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

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

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

разное

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

Расширения

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

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

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

Авторизация

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

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

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 не требует межклиентского взаимодействия и не определяет, как окна используются для формирования визуальных элементов, которые являются общими в графических пользовательских интерфейсах ( кнопки , меню и т. Д.). Элементы графического пользовательского интерфейса определяются клиентскими библиотеками, реализующими наборы инструментов для виджетов . Взаимодействие между клиентами регулируется другими стандартами, такими как спецификации ICCCM и freedesktop .

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

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

Смотрите также

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

Рекомендации

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

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