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

Логотип X Window System

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

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

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

Обзор [ править ]

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

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

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

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

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

Windows [ править ]

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

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

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

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

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

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

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

Пиксельные карты и рисунки [ править ]

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

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

Графические контексты и шрифты [ править ]

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

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

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

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

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

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

Ресурсы и идентификаторы [ править ]

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

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

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

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

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

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

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

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

События [ править ]

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

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

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

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-битные целые числа, представляющие строки . Разработчики протокола ввели атомы, потому что они представляют строки короткого и фиксированного размера: ^[9] хотя строка может быть произвольно длинной, атом всегда является 32-битным целым числом. Краткость Atom была использована путем предписания их использования в типах пакетов, которые, вероятно, будут отправлены много раз с одними и теми же строками; это приводит к более эффективному использованию сети. Фиксированный размер атомов использовался путем определения фиксированного размера для событий, а именно 32 байтов: пакеты фиксированного размера могут содержать атомы, а не длинные строки.

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

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

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

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

Свойства [ править ]

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

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

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

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

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

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

Сопоставления [ править ]

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

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

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

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

Захваты [ править ]

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

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

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

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

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

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

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

Другое [ править ]

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

Расширения [ править ]

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

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