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

Логотип X Window System

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

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

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

Обзор

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

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

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

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

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

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

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

Windows

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Окно
  • Pixmap
  • Шрифт
  • Цветовая карта (таблица цветов, описанная ниже)
  • Графический контекст

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

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

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

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

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

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

События

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

Цвета

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

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

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

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

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

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

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

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

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

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

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

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

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

Атомы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Захватывает

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

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

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

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

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

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

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

Другой

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

Расширения

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

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

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

Авторизация

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

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

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

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

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

Большинство клиентских программ связываются с сервером через Xlib клиентская библиотека. В частности, большинство клиентов используют такие библиотеки, как Xaw, Мотив, 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 и Мотив ) позволить клиентской программе указать функции обратного вызова связанные с некоторыми событиями; библиотека заботится об опросе очереди событий и вызове соответствующей функции при необходимости; некоторые события, например, указывающие на необходимость перерисовки окна, обрабатываются внутри Xt.

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

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

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

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

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

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

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

  1. ^ Роберт В. Шайфлер и Джеймс Геттис: X Window System: основные и дополнительные протоколы, X версии 11, выпуски 6 и 6.1, Digital Press 1996, ISBN  1-55558-148-X
  2. ^ RFC 1013
  3. ^ Грант Эдвардс. Введение в пользовательский интерфейс X11
  4. ^ Джим Геттис. Дорожная карта технологий открытого исходного кода В архиве 2 января 2006 г. Wayback Machine
  5. ^ "comp.fonts FAQ: X11 Info". www.faqs.org.
  6. ^ Джим Флауэрс; Стивен Гилдеа (1994). «Соглашения об описании шрифтов X Logical» (PDF). Корпорация цифрового оборудования. X Консорциум. Архивировано из оригинал (PDF) 28 марта 2005 г.. Получено 2005-12-30.
  7. ^ Матье Эррб и Матиас Хопф. Новые разработки в системе X Window.
  8. ^ "Интерфейс с ghostscript - Руководство GNU gv". www.gnu.org.
  9. ^ Дэвид Розенталь. Руководство по соглашениям о взаимодействии между клиентами. Стандарт консорциума MIT X, 1989 г.
  10. ^ а б "wm-spec". www.freedesktop.org.

внешняя ссылка