Как XCB отображает / выводит графические интерфейсы других процессов на экран?

Question

Я много читал об API XCB и собирал множество примеров с разных сайтов. Однако ни один из них не решает проблему создания реальных окон для приложений с графическим интерфейсом; они все как бы рисуют примитивную 2D-графику с помощью XCB. Например, создайте окно, нарисуйте несколько квадратов, закройте окно.

Как вы на самом деле заставляете процессы порождать свои окна в вашем оконном менеджере XCB?

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

Я также читал о том, как люди fork () обрабатывают сторонние процессы из своего оконного менеджера. Это кажется глупой идеей. Это? Разве приложения не должны работать независимо от оконного менеджера?

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

Я был бы очень признателен, если бы кто-то мог пролить свет на то, как вы должны обрабатывать создание окна приложения через XCB. Благодарю.

Answer 1

Однако ни один из них не решает проблему создания реальных окон для приложений с графическим интерфейсом;

В любом случае это не то, что вы хотите делать с API-интерфейсами на уровне протокола. Если вы хотите богатый графический интерфейс, используйте инструментарий, который сделает всю тяжелую работу за вас. Xlib / XCB предоставит вам только элементарные инструменты, которые хорошо работают для довольно простых окон; даже там я не начал бы проект, по крайней мере, не используя что-то вроде Каира.

Как вы на самом деле заставляете процессы порождать свои окна в вашем оконном менеджере XCB?

По телефону xcb_create_window а потом xcb_map_window, Вот и все. Это все. Вы создаете окно, а затем делаете его видимым.

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

Я могу только предположить, что, когда процесс сделан, X-сервер уведомлен

X-сервер не заботится о процессах.

направляет запрос в вашу заявку

какой запрос?

Разве приложения не должны работать независимо от оконного менеджера?

Ну да... но на самом деле время жизни оконного менеджера равно времени жизни X-сервера (люди обычно не переключают оконные менеджеры между ними). И без X-сервера все X-клиенты все равно умирают.

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

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

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

На самом деле рендеринг в окно - это то, что X-клиент будет делать сам с X-сервером.

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

---

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

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

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

Итак, теперь у нас есть X-клиент с перенаправлением подструктуры в корневом окне (наш WM). Теперь каждый раз, когда клиент запрашивает сопоставление окна, X-сервер вместо этого перенаправляет этот запрос клиенту оконного менеджера (через MapRequestEvent) и останавливается на этом. Единственное исключение из этого - запросы карт, поступающие от самого оконного менеджера: эти X-сервер будет обрабатывать (чтобы не вечно играть в пинг-понг с оконным менеджером).

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

И это все; Вот как работает отображение окна.

Как мой оконный менеджер должен сказать, когда создавать и отображать окно?

Оконный менеджер не говорит клиенту, что делать. Как он узнает, что клиент хочет делать? Все наоборот: клиент делает что-то, а оконный менеджер вмешивается и реагирует так, как считает нужным (в некоторых отношениях - оконный менеджер никоим образом не имеет полного контроля над X-сервером).

Есть ли какой-то цикл обработки событий, для которого мне нужно создать случай (где будет запрос на создание окна из X-сервера)?

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

Например, в случае отображения окна: клиент отправляет запрос карты и НЕ ДОЛЖЕН предполагать, что окно отображено (потому что оконный менеджер может отклонить запрос!). Клиент знает, что его окно было отображено, потому что когда это произойдет, X-сервер создаст MapEvent и отправит его клиенту.

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

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