История изменений

И чем тебе тут не угодил Wayland? Тем, что он ломает существующую архитектуру? Ну так это один из способов.

Мальчик, ты дурак? (c)

Более того, в Wayland можно выделить отдельно API для рисования в буфер и отдельно API для скрещивания этих буферов.

Нельзя. Wayland — это только и исключительно API для создания прямоугольников и отображения в них абстрактных сурфейсов. Ты вообще спецификации читал, нет?

Внезапно. А то, что X сервер последние пять лет (с приходом композитинга в массы) именно так и работает — это ничего?

Во-первых. Если он «так и работает», нахрена нужен вейланд? Выпилите из иксового протокола все неиспользуемые вызовы и опкоды и замените подсистему обработки раскладок на более вменяемую. ВСЁ. По твоей же логике, next-gen графическая система готова. Чо они там 5 лет проектируют этот композитор несчастный?

Во-вторых, если «X сервер именно так и работает», ты не расскажешь мне, что такое NETWM, Xrender, cairo xlib backend, OpenGL и почему без всего этого добра, которое «ненужно и не используется», весь линуксовый десктоп просто невозможен?

Здесь есть одна деталь — отделение тулкитов от их бекендов позволит в будущем перекраивать графическую систему вообще как угодно

Неправильно. Правильно так: «отделение кривых тулкитов от их кривых бэкэндов позволит в будущем доростить костыли даже до неба, даже до аллаха».

Вон замечательный пример с гонками www_linux_org_ru уже привел. И вот так у них всё.

Кроме того, какой, твою мать, абстрактный «бэкэнд» позволит мне реализовать панель задач или менеджер буфера обмена, или какой-нибудь i3wm так, чтобы он просто работал 10 лет без переписывания каждые полгода под новый набор костылей? (Хинт: это не та функциональность, которая покрывается тулкитом.) Без стабильного API, да. Даже без понимания необходимости проектирования такого API. Браво.

Приложение по своей сути в своих интерфейсных задачах обрабатывает ввод и рисует вывод. Это первичные сущности, это то место, по которому должно проходить стабильное и выверенное до миллиметра API. А все тулкиты — это просто внутренняя кухня приложения. Тулкиты приходят и уходят, задачи остаются те же самые.

Отсутствие такого API — это как если бы в Single Unix Specification отсутствовало API на операции с файлами. А чо, «тулкиты» справятся через прямые вызовы ядра.

И чем тебе тут не угодил Wayland? Тем, что он ломает существующую архитектуру? Ну так это один из способов.

Мальчик, ты дурак? (c)

Более того, в Wayland можно выделить отдельно API для рисования в буфер и отдельно API для скрещивания этих буферов.

Нельзя. Wayland — это только и исключительно API для создания прямоугольников и отображения в них абстрактных сурфейсов. Ты вообще спецификации читал, нет?

Внезапно. А то, что X сервер последние пять лет (с приходом композитинга в массы) именно так и работает — это ничего?

Во-первых. Если он «так и работает», нахрена нужен вейланд? Выпилите из иксового протокола все неиспользуемые вызовы и опкоды и замените подсистему обработки раскладок на более вменяемую. ВСЁ. По твоей же логике, next-gen графическая система готова. Чо они там 5 лет проектируют этот композитор несчастный?

Во-вторых, если «X сервер именно так и работает», ты не расскажешь мне, что такое NETWM, Xrender, cairo xlib backend, OpenGL и почему без всего этого добра, которое «ненужно и не используется», весь линуксовый десктоп просто невозможен?

Здесь есть одна деталь — отделение тулкитов от их бекендов позволит в будущем перекраивать графическую систему вообще как угодно

Неправильно. Правильно так: «отделение кривых тулкитов от их кривых бэкэндов позволит в будущем доростить костыли даже до неба, даже до аллаха».

Вон замечательный пример с гонками www_linux_org_ru уже привел. И вот так у них всё.

Кроме того, какой, твою мать, абстрактный «бэкэнд» позволит мне реализовать панель задач или менеджер буфера обмена, или какой-нибудь i3wm так, чтобы он просто работал 10 лет без переписывания каждые полгода под новый набор костылей? (Хинт: это не та функциональность, которая покрывается тулкитом.) Без стабильного API, да. Даже без понимания необходимости проектирования такого API. Браво.

Приложение по своей сути в своих интерфейсных задачах обрабатывает ввод и рисует вывод. Это первичные сущности, это то место, по которому должно проходить стабильное и выверенное до миллиметра API. А все тулкиты — это просто внутренняя кухня приложения. Тулкиты приходят и уходят, задачи остаются теже самые.

Отсутствие такого API — это как если бы в Single Unix Specification отсутствовало API на операции с файлами. А чо, «тулкиты» справятся через прямые вызовы ядра.

И чем тебе тут не угодил Wayland? Тем, что он ломает существующую архитектуру? Ну так это один из способов.

Мальчик, ты дурак? (c)

Более того, в Wayland можно выделить отдельно API для рисования в буфер и отдельно API для скрещивания этих буферов.

Нельзя. Wayland — это только и исключительно API для создания прямоугольников и отображения в них абстрактных сурфейсов. Ты вообще спецификации читал, нет?

Внезапно. А то, что X сервер последние пять лет (с приходом композитинга в массы) именно так и работает — это ничего?

Во-первых. Если он «так и работает», нахрена нужен вейланд? Выпилите из иксового протокола все неиспользуемые вызовы и опкоды и замените подсистему обработки раскладок на более вменяемую. ВСЁ. По твоей же логике, next-gen графическая система готова. Чо они там 5 лет проектируют этот композитор несчастный?

Во-вторых, если «X сервер именно так и работает», ты не расскажешь мне, что такое NETWM, Xrender, cairo xlib backend, OpenGL и почему без всего этого добра, которое «ненужно и не используется», весь линуксовый десктоп просто невозможен?

Здесь есть одна деталь — отделение тулкитов от их бекендов позволит в будущем перекраивать графическую систему вообще как угодно

Неправильно. Правильно так: «отделение кривых тулкитов от их кривых бэкэндов позволит в будущем доростить костыли даже до неба, даже до аллаха».

Вон замечательный пример с гонками www_linux_org_ru уже привел. И вот так у них всё.

Кроме того, какой, твою мать, абстрактный «бэкэнд» позволит мне реализовать панель задач или менеджер буфера обмена, или какой-нибудь i3wm так, чтобы он просто работал 10 лет без переписывания каждые полгода под новый набор костылей? (Хинт: это не та функциональность, которая покрывается тулкитом.) Без стабильного API, да. Даже без понимания необходимости проектирования такого API. Браво.

Приложение по своей сути в своих интерфесных задачах обрабатывает ввод и рисует вывод. Это первичные сущности, это то место, по которому должно проходить стабильное и выверенное до миллиметра API. А все тулкиты — это просто внутренняя кухня приложения. Тулкиты приходят и уходят, задачи остаются теже самые.

Отсутствие такого API — это как если бы в Single Unix Specification отсутствовало API на операции с файлами. А чо, «тулкиты» справятся через прямые вызовы ядра.