X Window System core protocol [1] [2] [3] является базовым протоколом X Window System , сетевой оконной системы для растровых дисплеев, используемых для создания графических пользовательских интерфейсов в Unix , Unix-подобных и других операционных системах . X Window System основана на клиент-серверной модели : один сервер управляет оборудованием ввода/вывода , таким как экран , клавиатура и мышь ; все прикладные программы действуют как клиенты , взаимодействуя с пользователем и другими клиентами через сервер. Это взаимодействие регулируется протоколом ядра X Window System. Существуют и другие протоколы , связанные с X Window System, как построенные на основе протокола ядра X Window System, так и как отдельные протоколы.
В основном протоколе X Window System только четыре вида пакетов отправляются асинхронно по сети: запросы, ответы, события и ошибки. Запросы отправляются клиентом на сервер, чтобы попросить его выполнить некоторую операцию (например, создать новое окно) и отправить обратно данные, которые он хранит. Ответы отправляются сервером, чтобы предоставить такие данные. События отправляются сервером, чтобы уведомить клиентов о действиях пользователя или других событиях, которые им интересны. Ошибки — это пакеты, отправляемые сервером, чтобы уведомить клиента об ошибках, возникших во время обработки его запросов. Запросы могут генерировать ответы, события и ошибки; кроме этого, протокол не предписывает определенный порядок, в котором пакеты отправляются по сети. Существуют некоторые расширения основного протокола, каждое из которых имеет свои собственные запросы, ответы, события и ошибки.
X был создан в MIT в 1984 году (его текущий [обновлять]релиз X11 появился в сентябре 1987 года). Его разработчики Боб Шейфлер и Джим Геттис установили в качестве раннего принципа, что его основной протокол должен был «создавать механизм, а не политику». В результате основной протокол не определяет взаимодействие между клиентами и между клиентом и пользователем. Эти взаимодействия являются предметом отдельных спецификаций, [4] таких как спецификации ICCCM и freedesktop.org , и обычно реализуются автоматически с помощью заданного набора виджетов .
Связь между сервером и клиентами осуществляется путем обмена пакетами по каналу . Соединение устанавливается клиентом (как запускается клиент, в протоколе не указано). Клиент также отправляет первый пакет, содержащий порядок байтов , который будет использоваться, и информацию о версии протокола и виде аутентификации, которую клиент ожидает от сервера. Сервер отвечает, отправляя обратно пакет, сообщающий о принятии или отклонении соединения, или запрос на дополнительную аутентификацию . Если соединение принято, пакет принятия содержит данные, которые клиент может использовать при последующем взаимодействии с сервером.
После установления соединения между клиентом и сервером по каналу происходит обмен четырьмя типами пакетов:
Пакеты запросов и ответов имеют различную длину, тогда как пакеты событий и ошибок имеют фиксированную длину в 32 байта .
Пакеты запросов нумеруются сервером последовательно, как только он их получает: первый запрос от клиента имеет номер 1, второй 2 и т. д. Младшие 16 бит последовательного номера запроса включаются в пакеты ответа и ошибок, сгенерированные запросом, если таковые имеются. Они также включаются в пакеты событий для указания последовательного номера запроса, который сервер в данный момент обрабатывает или только что завершил обработку.
То, что обычно называется окном в большинстве графических пользовательских интерфейсов , в системе X Window System называется окном верхнего уровня . Термин окно также используется для обозначения окон, которые находятся внутри другого окна, то есть подокна родительского окна . Графические элементы, такие как кнопки , меню , значки и т. д., могут быть реализованы с помощью подокнов.
Клиент может запросить создание окна. Точнее, он может запросить создание подокна существующего окна. В результате окна, созданные клиентами, располагаются в дереве ( иерархии). Корнем этого дерева является корневое окно , которое является специальным окном, автоматически создаваемым сервером при запуске. Все остальные окна являются прямыми или косвенными подокнами корневого окна. Окна верхнего уровня являются прямыми подокнами корневого окна. Видимо, корневое окно имеет такой же размер, как и виртуальный рабочий стол, и находится позади всех других окон.
Содержимое окна не всегда гарантированно сохраняется с течением времени. В частности, содержимое окна может быть уничтожено, когда окно перемещается, изменяет размер, перекрывается другими окнами и в целом становится полностью или частично невидимым. В частности, содержимое теряется, если X-сервер не поддерживает резервное хранилище содержимого окна. Клиент может запросить резервное хранилище для сохранения окна, но сервер не обязан это делать. Поэтому клиенты не могут предполагать, что резервное хранилище сохраняется. Если видимая часть окна имеет неопределенное содержимое, отправляется событие, уведомляющее клиента о том, что содержимое окна должно быть отрисовано снова.
Каждое окно имеет связанный с ним набор атрибутов , таких как геометрия окна (размер и положение), фоновое изображение, было ли запрошено для него резервное хранилище и т. д. Протокол включает запросы к клиенту на проверку и изменение атрибутов окна.
Окна могут быть InputOutputили InputOnly. InputOutputОкна могут отображаться на экране и использоваться для рисования. InputOnlyОкна никогда не отображаются на экране и используются только для получения входных данных.
.png/1280px-Xframe_(en).png)
Декоративная рамка и строка заголовка (возможно, включая кнопки), которые обычно видны вокруг окон, создаются менеджером окон , а не клиентом, который создает окно. Менеджер окон также обрабатывает ввод, связанный с этими элементами, например, изменение размера окна, когда пользователь щелкает и перетаскивает рамку окна. Клиенты обычно работают с окном, которое они создали, игнорируя изменения, произведенные менеджером окон. Изменение, которое он должен учитывать, заключается в том, что переродительские менеджеры окон , которыми являются почти все современные менеджеры окон, изменяют родителя окон верхнего уровня на окно, которое не является корневым. С точки зрения основного протокола менеджер окон является клиентом, не отличающимся от других приложений.
Данные об окне можно получить, запустив xwininfoпрограмму. Передав ей -tree аргумент командной строки , эта программа показывает дерево подокон окна вместе с их идентификаторами и геометрическими данными.
Пиксельная карта — это область памяти, которую можно использовать для рисования. В отличие от окон, пиксельные карты не отображаются на экране автоматически. Однако содержимое пиксельной карты (или ее часть) можно перенести в окно и наоборот. Это позволяет использовать такие методы, как двойная буферизация . Большинство графических операций, которые можно выполнять в окнах, можно выполнять и в пиксельными картами.
Окна и pixmaps совместно называются drawables , и их содержимое находится на сервере. Однако клиент может запросить передачу содержимого drawable с сервера на клиент или наоборот.
Клиент может запросить ряд графических операций, таких как очистка области, копирование области в другую, рисование точек, линий, прямоугольников и текста. Помимо очистки, все операции возможны для всех рисуемых объектов, как окон, так и пиксельных карт.
Большинство запросов на графические операции включают графический контекст , который представляет собой структуру, содержащую параметры графических операций. Графический контекст включает цвет переднего плана, цвет фона, шрифт текста и другие графические параметры. При запросе графической операции клиент включает графический контекст. Не все параметры графического контекста влияют на операцию: например, шрифт не влияет на рисование линии.
Основной протокол определяет использование шрифтов на стороне сервера. [5] Такие шрифты хранятся в виде файлов , и сервер обращается к ним либо напрямую через локальную файловую систему , либо через сеть из другой программы, называемой сервером шрифтов . Клиенты могут запрашивать список шрифтов, доступных серверу, и могут запрашивать загрузку шрифта (если он еще не загружен) или выгрузку (если он не используется другими клиентами) сервером. Клиент может запрашивать общую информацию о шрифте (например, подъем шрифта) и место, которое занимает конкретная строка при рисовании определенным шрифтом.
xfontselпозволяет пользователю просматривать глифы шрифта.Имена шрифтов представляют собой произвольные строки на уровне протокола ядра X Window. Соглашения об описании шрифтов X logical [6] определяют, как шрифты должны именоваться в соответствии с их атрибутами. Эти соглашения также определяют значения необязательных свойств, которые могут быть прикреплены к шрифтам.
Программа xlsfontsвыводит список шрифтов, хранящихся на сервере. xfontselПрограмма показывает глифы шрифтов и позволяет пользователю выбрать имя шрифта для вставки его в другое окно.
Использование серверных шрифтов в настоящее время считается устаревшим в пользу клиентских шрифтов. [7] Такие шрифты визуализируются клиентом, а не сервером, с поддержкой библиотек Xft или cairo и расширения XRender . Спецификация клиентских шрифтов в основном протоколе не приводится.
Все данные об окнах, пиксельных картах, шрифтах и т. д. хранятся на сервере. Клиент знает идентификаторы этих объектов — целые числа, которые он использует в качестве имен для них при взаимодействии с сервером. Например, если клиент хочет создать окно, он запрашивает у сервера создание окна с заданным идентификатором. Идентификатор может быть позже использован клиентом для запроса, например, строки, которая будет нарисована в окне. Следующие объекты находятся на сервере и известны клиенту по числовому идентификатору:
WindowPixmapFontColormap(таблица цветов, описанная ниже)Graphic contextЭти объекты называются ресурсами . Когда клиент запрашивает создание одного такого ресурса, он также указывает для него идентификатор. Например, для создания нового окна клиент указывает как атрибуты окна (родительский, ширина, высота и т. д.), так и идентификатор для связи с окном.
Идентификаторы — это 32-битные целые числа , три старших бита которых равны нулю. У каждого клиента есть свой набор идентификаторов, которые он может использовать для создания новых ресурсов. Этот набор указывается сервером как два целых числа, включенных в пакет принятия (пакет, который он отправляет клиенту, чтобы сообщить ему, что соединение принято). Клиенты выбирают идентификаторы, которые находятся в этом наборе, таким образом, чтобы они не конфликтовали: два объекта среди окон, пиксельных изображений, шрифтов, цветовых карт и графических контекстов не могут иметь одинаковый идентификатор.
После создания ресурса его идентификатор используется клиентом для запроса операций о нем на сервере. Некоторые операции затрагивают данный ресурс (например, запросы на перемещение окон); другие запрашивают данные о ресурсе, хранящиеся на сервере (например, запросы на атрибуты окон).
Идентификаторы уникальны для сервера, а не только для клиента; например, нет двух окон с одинаковым идентификатором, даже если они созданы двумя разными клиентами. Клиент может получить доступ к любому объекту по его идентификатору. В частности, он также может получить доступ к ресурсам, созданным любым другим клиентом, даже если их идентификаторы находятся за пределами набора идентификаторов, которые он может создать.
В результате два клиента, подключенных к одному и тому же серверу, могут использовать один и тот же идентификатор для ссылки на один и тот же ресурс. Например, если клиент создает окно идентификатора 0x1e00021и передает этот номер 0x1e00021другому приложению (любыми доступными способами, например, сохраняя этот номер в файле, который также доступен другому приложению), это другое приложение может работать с тем же самым окном. Эта возможность, например, используется версией Ghostview для X Window : эта программа создает подокно, сохраняя его идентификатор в переменной окружения , и вызывает Ghostscript ; эта программа рисует содержимое файла PostScript для отображения в этом окне. [8]
Ресурсы обычно уничтожаются, когда клиент, который их создал, закрывает соединение с сервером. Однако перед закрытием соединения клиент может попросить сервер не уничтожать их.
События — это пакеты, отправляемые сервером клиенту для сообщения о том, что произошло что-то, что может быть интересно клиенту. Например, событие отправляется, когда пользователь нажимает клавишу или щелкает кнопку мыши. События используются не только для ввода: например, события отправляются для указания на создание новых подокон данного окна.
Каждое событие относится к окну. Например, если пользователь щелкает, когда указатель находится в окне, событие будет относиться к этому окну. Пакет событий содержит идентификатор этого окна.
Клиент может запросить сервер отправить событие другому клиенту; это используется для связи между клиентами. Такое событие, например, генерируется, когда клиент запрашивает текст, который в данный момент выбран: это событие отправляется клиенту, который в данный момент обрабатывает окно, содержащее выбор.
Событие Exposeотправляется, когда область окна уничтожена и содержимое становится видимым. Содержимое окна может быть уничтожено в некоторых условиях, например, если окно закрыто, а сервер не поддерживает резервное хранилище. Сервер генерирует событие, Exposeчтобы уведомить клиента о том, что часть окна должна быть отрисована.
Большинство видов событий отправляются только в том случае, если клиент ранее выразил заинтересованность в них. Это связано с тем, что клиенты могут быть заинтересованы только в некоторых видах событий. Например, клиент может быть заинтересован в событиях, связанных с клавиатурой, но не в событиях, связанных с мышью. Однако некоторые виды событий отправляются клиентам, даже если они специально их не запрашивали.
Клиенты указывают, какие типы событий они хотят отправлять, устанавливая атрибут окна. Например, чтобы перерисовать окно, когда его содержимое было уничтожено, клиент должен получить Exposeсобытия, которые сообщают ему, что окно нужно перерисовать. Однако клиенту будут отправлены Exposeсобытия только в том случае, если он ранее заявил о своей заинтересованности в этих событиях, что делается путем соответствующей установки атрибута маски событий окна.
Разные клиенты могут запрашивать события в одном и том же окне. Они даже могут устанавливать разные маски событий в одном и том же окне. Например, клиент может запрашивать только события клавиатуры в окне, в то время как другой клиент запрашивает только события мыши в том же окне. Это возможно, поскольку сервер для каждого окна поддерживает отдельную маску событий для каждого клиента. Однако существуют некоторые виды событий, которые может выбрать только один клиент в каждый момент времени для каждого окна. В частности, эти события сообщают о щелчках кнопок мыши и некоторых изменениях, связанных с управлением окнами.
Программа xevпоказывает события относительно окна. В частности, xev -id WIDзапрашивает все возможные события относительно окна идентификатора WIDи выводит их.
Ниже приведен возможный пример взаимодействия сервера и программы, которая создает окно с черным ящиком и завершает работу при нажатии клавиши. В этом примере сервер не отправляет никакого ответа, поскольку клиентские запросы не генерируют ответы. Эти запросы могут генерировать ошибки.
0x0000002b) и идентификаторы, которые может создать клиент.0x00200000(этот запрос, как и другие запросы этого примера, не генерирует ответы от сервера)0x0000002b) с идентификатором 0x00200001, размером 200x200, позицией (10,10) и т. д.0x00200001, указывая, что он заинтересован в получении Exposeи KeyPressсобытиях.0x00200001отображение окна (отображение на экране)ExposeсобытиеPolyFillRectangleзапрос с окном 0x00200001и графическим контекстом.0x00200000Если окно закрыто другим окном и снова открыто, при условии, что резервное хранилище не поддерживается:
Exposeсобытие, чтобы сообщить клиенту, что окно необходимо перерисовать.PolyFillRectangleзапросЕсли нажата клавиша:
KeyPressсобытие клиенту, чтобы уведомить его о том, что пользователь нажал клавишу.На уровне протокола цвет представлен 32-битным целым числом без знака, называемым pixelvalue . На представление цветов влияют следующие элементы:
В самом простом случае цветовая карта представляет собой таблицу, содержащую тройку RGB в каждой строке. Пиксельное значение xпредставляет цвет, содержащийся в x-й строке таблицы. Если клиент может изменять записи в цветовой карте, это представление идентифицируется PseudoColor визуальным классом . Визуальный класс StaticColorаналогичен, но клиент не может изменять записи в цветовой карте.
Всего существует шесть возможных визуальных классов, каждый из которых определяет свой способ представления RGB-триплета с помощью пиксельного значения. PseudoColorи StaticColor— два. Еще два — GrayScaleи StaticGray, которые отличаются тем, что отображают только оттенки серого.
Два оставшихся визуальных класса отличаются от приведенных выше, поскольку они разбивают пиксельные значения на три части и используют три отдельные таблицы для интенсивности красного, зеленого и синего. Согласно этому цветовому представлению, пиксельное значение преобразуется в тройку RGB следующим образом:
Этот механизм требует, чтобы цветовая карта состояла из трех отдельных таблиц, по одной для каждого основного цвета . Результатом преобразования по-прежнему является тройка значений интенсивности. Визуальные классы, использующие это представление, — это DirectColorи TrueColor, отличающиеся тем, может ли клиент изменять цветовые карты или нет.
Эти шесть механизмов представления цветов с помощью пиксельных значений требуют для работы некоторых дополнительных параметров. Эти параметры собраны в визуальный тип , который содержит визуальный класс и другие параметры представления цветов. Каждый сервер имеет фиксированный набор визуальных типов, каждый из которых связан с числовым идентификатором. Эти идентификаторы представляют собой 32-битные целые числа без знака, но не обязательно отличаются от идентификаторов ресурсов или атомов.
Когда соединение от клиента принимается, пакет принятия, отправленный сервером, содержит последовательность блоков, каждый из которых содержит информацию об одном экране. Для каждого экрана относительный блок содержит список других блоков, каждый из которых относится к определенной цветовой глубине, поддерживаемой экраном. Для каждой поддерживаемой глубины этот список содержит список визуальных типов. В результате с каждым экраном связано несколько возможных глубин, а с каждой глубиной каждого экрана связано несколько возможных визуальных типов. Заданный визуальный тип может использоваться для большего количества экранов и для разных глубин.
Для каждого визуального типа пакет принятия содержит как его идентификатор, так и фактические параметры, которые он содержит (визуальный класс и т. д.). Клиент сохраняет эту информацию, так как не может запросить ее впоследствии. Более того, клиенты не могут изменять или создавать новые визуальные типы. Запросы на создание нового окна включают глубину и идентификатор визуального типа, который будет использоваться для представления цветов этого окна.
Карты цветов используются независимо от того, использует ли оборудование, управляющее экраном (например, графическая карта ) , палитру , которая представляет собой таблицу, также используемую для представления цветов. Серверы используют карты цветов, даже если оборудование не использует палитру. Всякий раз, когда оборудование использует палитры, может быть установлено только ограниченное количество карт цветов. В частности, карта цветов устанавливается, когда оборудование отображает цвета в соответствии с ней. Клиент может запросить сервер установить карту цветов. Однако для этого может потребоваться удаление другой карты цветов: в результате окна, использующие удаленную карту цветов, отображаются некорректным цветом, эффект, называемый цветным мерцанием или техниколором . Эту проблему можно решить с помощью стандартных карт цветов , которые представляют собой карты цветов с предсказуемой связью между значениями пикселей и цветами. Благодаря этому свойству стандартные карты цветов могут использоваться различными приложениями.
Создание цветовых карт регулируется конвенцией ICCCM . Стандартные цветовые карты регулируются ICCCM и спецификацией Xlib .
Частью системы X color является X Color Management System (xcms). Эта система была представлена в X11R6 Release 5 в 1991 году. Эта система состоит из нескольких дополнительных функций в xlib, найденных в серии функций Xcms*. Эта система определяет независимые от устройств цветовые схемы, которые могут быть преобразованы в зависимые от устройств системы RGB. Система состоит из функций xlib Xcms*, а также X Device Color Characterization Convention (XDCCC), которая описывает, как преобразовать различные независимые от устройств цветовые системы в зависимые от устройств цветовые системы RGB. Эта система поддерживает цветовые системы CIEXYZ , xyY , CIELUV и CIELAB , а также TekHVC. [1], [2]
Атомы — это 32-битные целые числа, представляющие строки . Разработчики протокола ввели атомы, поскольку они представляют строки короткого и фиксированного размера: [9] в то время как строка может быть произвольно длинной, атом всегда является 32-битным целым числом. Краткость атомов использовалась путем обязательного их использования в типах пакетов, которые, вероятно, будут отправляться много раз с одними и теми же строками; это приводит к более эффективному использованию сети. Фиксированный размер атомов использовался путем указания фиксированного размера для событий, а именно 32 байта: пакеты фиксированного размера могут содержать атомы, в то время как они не могут содержать длинные строки.
Точнее, атомы — это идентификаторы строк, хранящихся на сервере. Они похожи на идентификаторы ресурсов (Windows, Pixmaps и т. д.), но отличаются от них двумя способами. Во-первых, идентификаторы атомов выбираются сервером, а не клиентом. Другими словами, когда клиент запрашивает создание нового атома, он отправляет серверу только строку для сохранения, а не ее идентификатор; этот идентификатор выбирается сервером и отправляется обратно в качестве ответа клиенту. Второе важное отличие между ресурсами и атомами заключается в том, что атомы не связаны с клиентами. После создания атом сохраняется до тех пор, пока сервер не завершит работу или не выполнит сброс (это не поведение ресурсов по умолчанию).
Атомы являются идентификаторами и поэтому уникальны. Однако атом и идентификатор ресурса могут совпадать. Строка, связанная с атомом, называется именем атома . Имя атома не может быть изменено после создания, и никакие два атома не могут иметь одинаковое имя. В результате имя атома обычно используется для обозначения атома: «атом ABCD» означает, точнее, «атом, связанная строка которого ABCD.» или «атом, имя которого ABCD.» Клиент может запросить создание нового атома и может запросить атом (идентификатор) заданной строки. Некоторые атомы предопределены (создаются сервером с заданным идентификатором и строкой).
Атомы используются для ряда целей, в основном связанных с коммуникацией между различными клиентами, подключенными к одному и тому же серверу. В частности, они используются в сочетании со свойствами окон, которые описаны ниже.
Список всех атомов, находящихся на сервере, можно распечатать с помощью программы xlsatoms. В частности, эта программа печатает каждый атом (идентификатор, то есть число) с его именем (связанной с ним строкой).
Каждое окно имеет предопределенный набор атрибутов и набор свойств, которые хранятся на сервере и доступны клиентам через соответствующие запросы. Атрибуты — это данные об окне, такие как его размер, положение, цвет фона и т. д. Свойства — это произвольные фрагменты данных, прикрепленные к окну. В отличие от атрибутов, свойства не имеют значения на уровне протокола ядра X Window. Клиент может хранить произвольные данные в свойстве окна.
Свойство характеризуется именем, типом и значением. Свойства похожи на переменные в императивных языках программирования , в том смысле, что клиент может создать новое свойство с заданным именем и типом и сохранить в нем значение. Свойства связаны с окнами: два свойства с одинаковым именем могут существовать в двух разных окнах, имея разные типы и значения.
Имя, тип и значение свойства являются строками; точнее, они являются атомами, то есть строками, хранящимися на сервере и доступными клиентам через идентификаторы. Клиентское приложение может получить доступ к заданному свойству, используя идентификатор атома, содержащего имя свойства.
Свойства в основном используются для межклиентской коммуникации. Например, свойство с именем WM_NAME(свойство, названное атомом, связанная строка которого — "WM_NAME") используется для хранения имени окон. Оконные менеджеры обычно считывают это свойство для отображения имени окон в их заголовке.
Некоторые типы межклиентской коммуникации используют свойства корневого окна. Например, согласно спецификации менеджера окон freedesktop [10] , менеджеры окон должны хранить идентификатор текущего активного окна в свойстве, названном _NET_ACTIVE_WINDOWкорневым окном. Ресурсы X , которые содержат параметры программ, также хранятся в свойствах корневого окна; таким образом, все клиенты могут получить к ним доступ, даже если они запущены на разных компьютерах.
Программа xpropвыводит свойства заданного окна; xprop -rootвыводит имя, тип и значение каждого свойства корневого окна.
/, 7и {связаны с тремя различными символами клавиши .В системе X Window каждая индивидуальная физическая клавиша связана с числом в диапазоне 8–255, называемым ее keycode . Keycode идентифицирует только клавишу, а не конкретный символ или термин (например, «Page Up») среди тех, которые могут быть напечатаны на клавише. Каждый из этих символов или терминов вместо этого идентифицируется keysym . В то время как keycode зависит только от фактической нажатой клавиши, keysym может зависеть, например, от того, была ли также нажата клавиша Shift или другой модификатор .
При нажатии или отпускании клавиши сервер отправляет события типа KeyPressили KeyReleaseсоответствующим клиентам. Эти события содержат:
Поэтому сервер отправляет код клавиши и состояние модификатора, не пытаясь преобразовать их в определенный символ. Клиент несет ответственность за выполнение этого преобразования. Например, клиент может получить событие, сообщающее о том, что заданная клавиша была нажата, когда модификатор Shift был нажат. Если эта клавиша обычно генерирует символ «a», клиент (а не сервер) связывает это событие с символом «A».
В то время как перевод кодов клавиш в символы клавиш выполняется клиентом, таблица, представляющая эту связь, поддерживается сервером. Сохранение этой таблицы в централизованном месте делает ее доступной для всех клиентов. Типичные клиенты только запрашивают это сопоставление и используют его для декодирования поля кода клавиши и модификаторов события клавиши в символ клавиши. Однако клиенты также могут изменять это сопоставление по своему желанию.
Модификатор — это клавиша, нажатие которой изменяет интерпретацию других клавиш. Распространенным модификатором является клавиша Shift : когда клавиша, которая обычно производит строчную «a», нажимается вместе с Shift, она производит заглавную «A». Другими распространенными модификаторами являются «Control», «Alt» и «Meta».
X-сервер работает максимум с восемью модификаторами. Однако каждый модификатор может быть связан с более чем одной клавишей. Это необходимо, поскольку многие клавиатуры имеют дублирующие клавиши для некоторых модификаторов. Например, многие клавиатуры имеют две клавиши "Shift" (одну слева и одну справа). Эти две клавиши при нажатии выдают два разных кода клавиш, но X-сервер связывает обе с модификатором "Shift".
Для каждого из восьми модификаторов X-сервер поддерживает список кодов клавиш, которые он считает этим модификатором. Например, если список первого модификатора (модификатор "Shift") содержит код клавиши 0x37, то клавиша, которая создает код клавиши, 0x37считается X-сервером клавишей Shift.
Списки сопоставлений модификаторов поддерживаются X-сервером, но могут быть изменены каждым клиентом. Например, клиент может запросить добавление клавиши "F1 " в список модификаторов "Shift". С этого момента эта клавиша ведет себя как другой модификатор shift. Однако при нажатии этой клавиши по-прежнему генерируется код клавиши, соответствующий F1. В результате F1 работает так же, как и раньше (например, при ее нажатии может быть открыто окно справки), но также работает как клавиша shift (нажатие "a" в текстовом редакторе при нажатой клавише F1 добавляет "A" к текущему тексту).
X-сервер поддерживает и использует сопоставление модификаторов для кнопок мыши. Однако кнопки можно переставлять только . Это в основном полезно для обмена левой и правой кнопками для левшей .
Программа xmodmapпоказывает и изменяет назначения клавиш, модификаторов и кнопок мыши.
Захват — это состояние, при котором все события клавиатуры или мыши отправляются одному клиенту. Клиент может запросить захват клавиатуры, мыши или и того, и другого: если запрос выполнен сервером, все события клавиатуры/мыши отправляются захватывающему клиенту до тех пор, пока захват не будет отпущен. Другие клиенты не получат эти события.
При запросе захвата клиент указывает окно захвата : все события отправляются клиенту захвата, как если бы они были относительно окна захвата. Однако другие клиенты не получают события, даже если они выбрали их в окне захвата. Существует два вида захватов:
Клиент может установить захват клавиатуры, указателя или и того, и другого. Запрос на захват может включать запрос на заморозку клавиатуры или указателя. Разница между захватом и заморозкой заключается в том, что захват изменяет получателя событий, тогда как заморозка полностью останавливает их доставку. Когда устройство заморожено, генерируемые им события сохраняются в очереди для доставки в обычном режиме после окончания заморозки.
Для событий указателя на доставку событий влияет дополнительный параметр: маска событий, которая указывает, какие типы событий должны быть доставлены, а какие должны быть отброшены.
Запросы на захват включают поле для указания того, что происходит с событиями, которые будут отправлены захватывающему клиенту, даже если он не установил захват. В частности, клиент может запросить их отправку как обычно или в соответствии с захватом. Эти два условия не одинаковы, как может показаться. Например, клиент, который обычно получает события клавиатуры в первом окне, может запросить захват клавиатуры вторым окном. События, которые обычно отправляются в первое окно, могут быть перенаправлены в окно захвата или нет в зависимости от параметра в запросе захвата.
Клиент также может запросить захват всего сервера. В этом случае сервер не будет обрабатывать ни один запрос, кроме тех, которые исходят от клиента, осуществляющего захват.
Существуют и другие запросы и события в основном протоколе. Первый тип запросов относится к родительским отношениям между окнами: клиент может запросить изменение родителя окна или запросить информацию о родительстве окон. Другие запросы относятся к выбору , который, однако, в основном регулируется другими протоколами. Другие запросы относятся к фокусу ввода и форме указателя . Клиент также может запросить уничтожение владельца ресурса (окна, pixmap и т. д.), что заставит сервер разорвать соединение с ним. Наконец, клиент может отправить серверу запрос на отсутствие операции .
Основной протокол X Window был разработан с расчетом на расширение. Основной протокол определяет механизм запроса доступных расширений и то, как выполняются запросы расширения, события и пакеты ошибок.
В частности, клиент может запросить список всех доступных расширений для данных, относящихся к определенному расширению. Пакеты расширений аналогичны пакетам основного протокола. Основной протокол указывает, что пакеты запроса, события и ошибки содержат целое число, указывающее его тип (например, запрос на создание нового окна имеет номер 1). Диапазон этих целых чисел зарезервирован для расширений.
Когда клиент изначально устанавливает соединение с сервером, сервер может ответить, приняв соединение, отклонив его или запросив аутентификацию . Запрос аутентификации содержит имя используемого метода аутентификации. Основной протокол не определяет процесс аутентификации, который зависит от типа используемой аутентификации, за исключением того, что он заканчивается отправкой сервером пакета принятия или отказа.
Во время обычного взаимодействия между клиентом и сервером единственные запросы, связанные с аутентификацией, касаются метода доступа на основе хоста . В частности, клиент может запросить включение этого метода и запросить чтение и изменение списка хостов ( клиентов ), которым разрешено подключаться. Типичные приложения не используют эти запросы; они используются программой xhostдля предоставления пользователю или скрипту доступа к списку доступа хоста. Метод доступа на основе хоста считается небезопасным.
Большинство клиентских программ взаимодействуют с сервером через клиентскую библиотеку Xlib . В частности, большинство клиентов используют такие библиотеки, как Xaw , Motif , GTK+ или Qt , которые в свою очередь используют Xlib для взаимодействия с сервером. Использование Xlib имеет следующие эффекты:
XFlush;XGetWindowAttributes;XNextEvent), и вызов блокируется (например, XNextEventблокируется, если очередь пуста).Библиотеки более высокого уровня, такие как Xt (которая, в свою очередь, используется Xaw и Motif ), позволяют клиентской программе указывать функции обратного вызова , связанные с некоторыми событиями; библиотека берет на себя опрос очереди событий и вызов соответствующей функции при необходимости; некоторые события, такие как те, которые указывают на необходимость перерисовки окна, обрабатываются внутри Xt.
Библиотеки более низкого уровня, такие как XCB , обеспечивают асинхронный доступ к протоколу, позволяя лучше скрывать задержки.
Основной протокол X Window System не регламентирует межклиентское взаимодействие и не определяет, как окна используются для формирования визуальных элементов, которые являются общими для графических пользовательских интерфейсов ( кнопки , меню и т. д.). Элементы графического пользовательского интерфейса определяются клиентскими библиотеками, реализующими наборы инструментов для виджетов . Межклиентское взаимодействие регулируется другими стандартами, такими как спецификации ICCCM и freedesktop . [10]
Межклиентское взаимодействие относится к выделениям, буферам вырезания и перетаскиванию , которые являются методами, используемыми пользователем для передачи данных из одного окна в другое. Поскольку окна могут управляться разными программами, необходим протокол для обмена этими данными. Межклиентское взаимодействие также относится к менеджерам окон X , которые являются программами, управляющими внешним видом окон и общим внешним видом графического пользовательского интерфейса.
Еще одним вопросом, где межклиентское общение в определенной степени актуально, является управление сеансами .
То, как запускается сеанс пользователя, — это еще одна проблема, которая не охватывается основным протоколом. Обычно это делается автоматически диспетчером отображения X. Однако пользователь может также запустить сеанс вручную, запустив программы xinit или startx .