А можно нормально объяснить что в «композите» который заключается, судя по ссылке, всего лишь в возможности поместить gc на 3d текстуру конкретно есть такого, что действительно требует вэйланда, а не расширения X11, а не писать всякую туфту?

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

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

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

Если я ставлю голые иксы + xterm и делаю startx - там разве будет какой то оконный менеджер?

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

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

> У вялендописателей есть и аргументы, прочитай их.

Я их все прочитал еще в начале первого вялендосрача здесь. Я бы не имел против вяленда вообще ничего, если бы он планировал быть бэкендом отрисовки X-сервера. Но он хочет быть чем-то большим и с тупым подростковым упорством форсит «иксы тормозят и устарели!!!11». Хотя бы поэтому его стоит закопать.

Программы, написанные на X11 выглядят жутко уродливо

А дельфикодеры жутко глупы.

rdp работает лучше чем X11.

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

>И да, покажите хоть одно линуксячье приложение, которое не будет работать без оконного менеджера. Любое, хоть самое дебильное.
Сейчас меня обвинят в буквоедстве.
xmobar, bmpanel, tint2.

всего лишь в возможности поместить gc на 3d текстуру

Кто сказал, что она 3d? На 3d её натягивают отдельные экземпляры композитных менеджеров в отдельных эффектах. В том же expose я не замечал 3d.
Композит в иксах сейчас тормозит (а ещё не работает с xinerama, но это мало кого волнует). Сделаешь лучше — будет меньше надобности в wayland (неисправимых race conditions, о которых рассказано в pdf'ке выше по треду, естественно, это не отменит).

Я их все прочитал еще в начале первого вялендосрача здесь. Я бы не имел против вяленда вообще ничего, если бы он планировал быть бэкендом отрисовки X-сервера. Но он хочет быть чем-то большим и с тупым подростковым упорством форсит «иксы тормозят и устарели!!!11». Хотя бы поэтому его стоит закопать.

Если тебя просто пугают перемены, тебе надо не вяленого обсерать а к доктору наведаться.

Программы, написанные на X11 выглядят жутко уродливо

А дельфикодеры жутко глупы.

А можно поинтересеваться, они то тут причём?!

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

Запускается и работает. И при этом самому гимпу - абсолютно наплевать, есть оконный менеджер и или нет, где размещены его окошки - на текстурах или на экране. Запускаю twm какой-нибудь - он окошки гимпа окучивает. Прибиваю twm, запускаю kwin - тоже никаких проблем. Гимпу похрену. Так что гимп никак не годится в качестве примера.

Так, ещё варианты X11 приложений не работающих без WM есть?

Ну вот, разговор с тобой опять скатывается в нечто тягучее и унылое.

WTF qtperf ?

Интересно посмотреть в потроха qtperf.

У меня вот возникли замечания:

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

Во-вторых - в тесте измеряется время на отрисовку виджетов в QImage.
Очевидно, что растровый backend имеет в этом случае фору. Но если мы хотим обсуждать «скорость появления изображения на экране», то эта подмена недопустима.

В третьих - измерять скорость рисования пустых виджетов (типа QTableWidget) с практической точки зрения бесполезно.

В противоположность этому «сферическому в вакууме» тесту gtkperf честно рисует на экране.
Найдётся доброволец написать аналог gtkperf?

Запускается и работает.

И как удобно?!

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

Собственно как и любому приложению Qt или GTK собранному с поддержкой вяленого )))

Запускаю twm какой-нибудь - он окошки гимпа окучивает. Прибиваю twm, запускаю kwin - тоже никаких проблем.

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

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

rdp работает не несколько лучше. Для edge соединения разница между X11 и rdp как между «не работает» и «работает».

хочешь сказать xterm, xclock и xeyes - образец красоты и удобства?

Я бы не имел против вяленда вообще ничего, если бы он планировал быть бэкендом отрисовки X-сервера.

facepalm.xpm

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

Почитай этот текст http://blogs.msdn.com/b/e7/archive/2009/04/25/engineering-windows-7-for-graph...

и сравни описанное с многократным копированием памяти в иксах.

> Сейчас меня обвинят в буквоедстве.

xmobar, bmpanel, tint2.

Судя по названию - это какие-то панельки или примочки именно для WM.
Запускать их через сеть, как и сам WM просто нет смысла. Так что не прокатит.

Кто сказал, что она 3d? На 3d её натягивают отдельные экземпляры

композитных менеджеров в отдельных эффектах. В том же expose я не

замечал 3d.

О том и речь - какая разница, 3d или нет? Это дело оконного менеджера окошки куда-то там помещать. А не приложения.

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

Ну вот хоть убейте не пойму я.
Криво написанные тулкиты ради рюшечек гоняют пиксмапы. Это долго и ресурсоёмко. Вместо того, чтобы написать расширение для Х11 добавляющее рюшечки для тулкита (никто ведь не умрёт, если в комплекте с gtk будет идти модуль к Х11), нужно зачем-то иксы убрать, вместо них сделать какой-то вэйланд и переписать заново весь графический вывод тулкита.
Ну будет на удалённой машине с Х сервером без gtkшного модуля приложение выглядеть как Х11 native, что с того? Никто не умрёт, если кнопочка в запущенной _удалённо_ софтине будет не округлая и выпуклая, а в виде прямоугольника с чёрной рамкой. Да и то это легко решится установкой того самого модуля рюшечек GTK для X11. При этом, сам GTK ставить не надо.

программа написанная скажем под winxp выглядит как неродная через rdp в windows7. и наоброт. это при том что изменения там - минимальные. и «тулкит» только один просто разных версий. желание же тех кто поддерживает вайленд уничтожить конкурирующие тулкиты «пропустив» их через кривонаписанный уровень «совместимости» очевидно...

> Собственно как и любому приложению Qt или GTK собранному с поддержкой вяленого )))

Так нахрена тогда вяленый, если он НИЧЕГО не даёт по сравнению с Х11?

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

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

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

И зачем тогда вяленый, если это всё уже давным-давно работает в иксах?

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

Так нахрена тогда вяленый, если он НИЧЕГО не даёт по сравнению с Х11?

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

«Ну вот хоть убейте не пойму я. Криво написанные тулкиты ради рюшечек гоняют пиксмапы. Это долго и ресурсоёмко. Вместо того, чтобы написать расширение для Х11 добавляющее рюшечки для тулкита (никто ведь не умрёт, если в комплекте с gtk будет идти модуль к Х11), нужно зачем-то иксы убрать, вместо них сделать какой-то вэйланд и переписать заново весь графический вывод тулкита» вот и я не пойму. почему люди не осилившие X (а расширяемость есть часть архитектуры X) уверенны что дело именно в X. а не в их головах...

И зачем тогда вяленый, если это всё уже давным-давно работает в иксах?

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

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

Он создан не что-бы дать что-то новое, я уже писал об этом.

>Иксы слишком долго не умели рисовать градиенты, нормальные шрифты и прочее, в итоге все это реализовали в тулкитах, а в иксы стали гнать картинку.

Нормальные шрифты рестеризуются на клиенте и загружаются на сервер и хранятся там в виде GlyphSet. Для написания строчки текста X-клиент гонит на X-сервер не картинку, а последовательность индексов. См. раздел Test Rendering здесь: http://keithp.com/~keithp/talks/usenix2001/xrender/ Я сильно сомневаюсь, что текстовые области кто-то рендерит у себя и отсылает картинкой на сервер. Нужны пруфы, кто так делает и в каких случаях. Впрочем, это не противоречит идеологии X.

> А на кой нужно для сетевой прозрачности делать в тулкитах дополнительные бекенды, использующие древний протокол?!

1. Для совместимости. 2. Древний протокол жмёт так, как не снилось никакому алгоритму сжатия графики. Расскажите мне, сколько мегабайт будет передано софтиной использующей вэйланд, которая создаёт окно размером 2000х1000 пикселей в 32-битном цвете и пишет на нём много мелкого текста или сложную векторную картинку. Сколько мегабайт надо передать чтобы поменять цвет фона этого окошка.

> или сложную векторную картинку

сложную векторную картинку средствами X-в никто не рисует - медленно

>Криво написанные тулкиты ради рюшечек гоняют пиксмапы.
Прямо написанные тулкиты даже текст вынуждены гонять отрендеренным. Потому, что иксы до сих пор не умеют юникод (под умением юникода я понимаю UCS-4 с поддержкой как минимум трёх основных направлений, отдельных языков для любого куска текста (зачем? спрашивать у упорков, сделавших юникод), лигатур. Blurry fonts, на который так любят испражняться кирпичами нелюбители лишних зависимостей, опциональны).

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

Во-первых, приложению есть разница. Приложение получает не одно событие при каждом показе своего окна.
Во-вторых, ты собираешься писать по расширению к иксам на _каждую_ фичу композитного менеджера? Это с какой же частотой иксы будут падать… Не собираешься? Гоняй отрендеренную картинку от приложения к композитному менеджеру _через_ иксы.

Ну будет на удалённой машине с Х сервером без gtkшного модуля приложение выглядеть как Х11 native

Эм. X11 native не существует. Даже Xt — относительно независим.

переписать заново весь графический вывод тулкита.

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

И напоминаю: в X11 тонны нерешаемых проблем даже помимо скорости композитинга.

тупой или прикидываешься?есть тулбар. есть загружееные при старте картинки избражающие его кнопки в разных состояниях (скажем активного использования, задисейбленного ну и скажем - редактирование самого тулбара.плюс картинки для для обрамления) что эффективнее передать команды disable(id1,id2,id3) или там команды acticateImage(disid1) acticateImage(disid2) acticateImage(disid3) ? или гонять картинки?

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

Я думаю, что RDP работает лучше X11 на слабых каналах, потому что там round-trips нет. Впрочем, все команды отрисовки в X11 не подвержены этой фигне, так как ответов не требуют. round-trips в других местах протокола появляются. К тому же, в голом X11 не предусмотрено сжатие графики (совершенно справедливо, ИМХО, потому что способов сжатия может быть стопятсот). Всю эту фигню надо делать на проксиуровнях. Корректнее сравнивать RDP с NX. Но фишка в том, что адекватного сравнения не получится, так как и ОС разные, и содержимое десктопов принципиально разное. Однако я читал чьи-то отзывы: люди говорили, что по их ощущениям NX отзывчевее, чем RDP.

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

Едрить....Ну что за тупизна-то, ёкарный бабай?

1. По-идиотски делается тулкит, который зачем-то гоняет пиксмапы туда-сюда, вместо того, чтобы просто пользовать примитивы Х11. 2. Разумеется из-за уродского тулкита начинает тормозить графика. 3. Чтобы графика не тормозила нужно для уродского тулкита написать какой-то вяленый, а иксы убрать.

ЗАЧЕМ весь этот маразм, если для решения проблемы с тормозами нужно всего лишь перетащить рюшечки (темы эти сраные и всё такое) тулкита в модуль Х11 для этого тулкита, а на стороне клиента оставить только рисование примитивов?

Зачем нужно с огромным геморроем лечить последствия, когда можно устранить причину?

1. Для совместимости.

Нахрена она нужна?!

2. Древний протокол жмёт так, как не снилось никакому алгоритму сжатия графики.

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

Расскажите мне, сколько мегабайт будет передано софтиной использующей вэйланд, которая создаёт окно размером 2000х1000 пикселей в 32-битном цвете и пишет на нём много мелкого текста или сложную векторную картинку. Сколько мегабайт надо передать чтобы поменять цвет фона этого окошка.

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

>Запускать их через сеть, как и сам WM просто нет смысла. Так что не прокатит.
Ок. Тогда ход конём.
Виртуальная клавиатура. Кстати, оконные менеджеры, в которых они работают без проблем, можно пересчитать по пальцам.

> сложную векторную картинку средствами X-в никто не рисует - медленно

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

> Ага, и вместо того, чтобы научить иксы рисовать примитивы быстрее, нужно изобретать велосипед в своей программе и грузить иксы пиксмапом.

не вопрос - научи, у людей видишь не получается

> Ок. Тогда ход конём.

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

Так она, во-первых, запускается локально, и по-уму должна всего лишь гнать сообщения о нажатии в /dev/input/eventXX, а во-вторых иксы с локальным оконным менеджером уже разберутся чего и куда, какое нажатие локально обработать, а какое - удалённому клиенту отправить.

1. По-идиотски делается тулкит, который зачем-то гоняет пиксмапы туда-сюда, вместо того, чтобы просто пользовать примитивы Х11.

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

2. Разумеется из-за уродского тулкита начинает тормозить графика.

У меня ничего не тормозит, но ресурсы на это расходуются лишние.

3. Чтобы графика не тормозила нужно для уродского тулкита написать какой-то вяленый, а иксы убрать.

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

ЗАЧЕМ весь этот маразм, если для решения проблемы с тормозами нужно всего лишь перетащить рюшечки (темы эти сраные и всё такое) тулкита в модуль Х11 для этого тулкита, а на стороне клиента оставить только рисование примитивов?

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

Зачем нужно с огромным геморроем лечить последствия, когда можно устранить причину?

Вот вяленый и есть устранение причины, причина кроется в убогости иксов.

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

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

>во-вторых иксы с локальным оконным менеджером уже разберутся чего и куда, какое нажатие локально обработать, а какое - удалённому клиенту отправить.
Вот, уже 3 программы должны быть на одной машине. Это только начало сетевой прозрачности и мы ещё не прикасались к синхронизации всего этого по сети.

по-уму должна всего лишь гнать сообщения о нажатии в /dev/input/eventXX

С дуба рухнул? Какой /dev/ в X11???
Прокидывать ФС поверх X11 мне когда-то тоже приходило в голову. Этакий кросс-десктопный прозрачный по сети VFS.
Вроде бы ничего не употребляю, выдыхать нечего…

> Корректнее сравнивать RDP с NX

Поэтому я и сказал про «переработанный» и «15 лет позже». Вялендофилы же хотят всё с нуля, чего даже MS с ее миллиардами делать не стала.

> Потому, что иксы до сих пор не умеют юникод (под умением юникода я понимаю UCS-4 с поддержкой как минимум трёх основных направлений, отдельных языков для любого куска текста (зачем? спрашивать у упорков, сделавших юникод), лигатур

кто-то запрещает научить XDrawString понимать юникод?

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

Ну и пусть получает. Размер там, запрос на перерисовку и т.п. Но пиксмап-то экрана нахера?

Во-вторых, ты собираешься писать по расширению к иксам на _каждую_ фичу композитного менеджера? Это с какой же частотой иксы будут падать…

Один модуль реализующий все нужные тулкиту фичи.
И при чём тут этот чортов композитный менеджер?

Не собираешься? Гоняй отрендеренную картинку от приложения к композитному менеджеру _через_ иксы.

Зачем?
Я не понимаю. Правда.

Приложение с кнопкой в окне. Оно шлёт команды:

Создать главное окно с фичей «использовать модуль тулкита ХХХ».
Создать дочернее окно кнопки
Нарисовать прямоугольник с фичей «рамка и фон кнопки»
Написать текст

Х сервер. Делает следующее:

Загружает модуль тулкита, если не загружен. Если нету - то ничего страшного.
Создаёт главное окно
Создаёт дочернее окно кнопки
Если модуль тулкита есть - то отдаёт ему рисование фона кнопки, если нет - то рисует дефолтный прямоугольник.
Пишет текст.

Что в этом алгоритме требует обмена пиксмапами? Где тут необходимость всяких композитингов?
Ну хоть какой-то пример вменяемый и понятный можно?
А ведь это 99% рисования на экране для современных приложений.
Гонять пиксмапы требуется только если мы показываем пользователю реальные картинки - фотки там, или иконки.

> Если модуль тулкита есть - то отдаёт ему рисование фона кнопки, если нет - то рисует дефолтный прямоугольник.

не обижайся - но у тебя детский взгляд на то, как все работает

> Вот, уже 3 программы должны быть на одной машине. Это только начало сетевой прозрачности и мы ещё не прикасались к синхронизации всего этого по сети.

Они есть. В чём проблема?

С дуба рухнул? Какой /dev/ в X11???

Прокидывать ФС поверх X11 мне когда-то тоже приходило в голову. Этакий кросс-десктопный прозрачный по сети VFS. Вроде бы ничего не употребляю, выдыхать нечего…

Локальный /dev/ разумеется. Который обслуживают модули input/*_drv.so из комплекта X-сервера.

Зачем мне может понадобится клавиатура _удалённой_ машины?

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

сколько сток кода x.org лично ты поменял?

Приложение с кнопкой в окне. Оно шлёт команды:

Создать главное окно с фичей «использовать модуль тулкита ХХХ».
Создать дочернее окно кнопки
Нарисовать прямоугольник с фичей «рамка и фон кнопки»
Написать текст

Х сервер. Делает следующее:

Загружает модуль тулкита, если не загружен. Если нету - то ничего страшного.
Создаёт главное окно
Создаёт дочернее окно кнопки
Если модуль тулкита есть - то отдаёт ему рисование фона кнопки, если нет - то рисует дефолтный прямоугольник.
Пишет текст.

Что мешает сделать бекенд для тулкита который: перехватывает поток команд рисования (можно даже на уровне тех самых виджетов, о которых ты говоришь) и шлёт по сети, по прибытии в пункт назначения средствами этого же тулкита рисует (можно даже с учетом локальной темы если перехватывать инфу о виджетах, а не непосредственно команды рисования)?!

>кто-то запрещает научить XDrawString понимать юникод?
А переписывать старый софт (включая закрытый) будешь лично ты? Об обратной совместимости когда-нибудь думал?

Один модуль реализующий все нужные тулкиту фичи.

Каждого тулкита каждой версии. С учётом того, что всё это работает с правами root'а, получаем неплохое такое решето. А ещё нужна лишняя память на второй экземпляр тулкита.
Кстати, тулкиты занимаются далеко не только отрисовкой.
Почему 2 экземпляра тулкита? Приложение _обязано_ работать по сети. По сети может быть древний UNIX (tm) с X-сервером, не представляющим о твоём гениальном решении. Попробуй описать, как оно должно работать в этом случае без термина «пиксмап» и мата.
Если будешь опять ссылаться на дефолтные прямоугольники — смотри ниже.

Создаёт дочернее окно кнопки

Привет тормозам и проблемам с синхронизацией. Не от хорошей жизни тулкиты сейчас избавляются от всех этих дочерних окон…

Если модуль тулкита есть - то отдаёт ему рисование фона кнопки, если нет - то рисует дефолтный прямоугольник.

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

Где тут необходимость всяких композитингов?

В оконном менеджере при переключении окон (включая expose).

>Локальный /dev/ разумеется. Который обслуживают модули input/*_drv.so из комплекта X-сервера.
То есть мы привязываемся к юникс-лайк системам с /dev/input (это достаточно узкая группа) и правам суперпользователя. Прекрасно. Для задумывавшихся кроссплатформенными иксов.
Собственно, если иксы контролируют _весь_ ввод, доступный приложениям (как ни на что не годный core, так и всякие xinput2), нафиг им слать события куда-то наружу? Они могут слать события любому окну и без этого.

1. Для совместимости.

кто-то запрещает научить XDrawString понимать юникод?

Ты уж реши чего хочешь, совместимости или нормальной современной графики. Такова жизнь.

> не обижайся - но у тебя детский взгляд на то, как все работает

Мать-мать-мать!!! Ну, едрёна кочерыжка, напишите же не по-детски уже как всё работает, и где там нужен вэйланд вместо Х11, только без этого дебильного суржика с «композитингом» и прочей херотой.

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

> Ты уж реши чего хочешь, совместимости или нормальной современной графики. Такова жизнь.

ты что, идиот? по-твоему, переход с ru_RU.KOI8-R на ru_RU.UTF-8 сломал всю совместимость?

кстати, я повторяю вопрос про кол-во строк кода.

>по-твоему, переход с ru_RU.KOI8-R на ru_RU.UTF-8 сломал всю совместимость?
По-твоему, иксы везде понимают хотя бы ru_RU.KOI8-R? Тебя ждёт большой сюрприз в спецификации протокола.

только без этого дебильного суржика с «композитингом» и прочей херотой.

Пользуй ncurses он «без этого дебильного суржика с „композитингом“ и прочей херотой», а людям нужна нормальная современная графика. А так же тебя никто не запрещает в будующем ставить себе X11 с иксовыми программами и дрочить на графику 80 годов прошлого века :)

Толсто тролишь, ещё и анонимус...

> То есть мы привязываемся к юникс-лайк системам с /dev/input (это достаточно узкая группа) и правам суперпользователя. Прекрасно. Для задумывавшихся кроссплатформенными иксов.

А на любой машине будет /dev/input или там драйвер клавиатуры, с которым будет общаться то, что организует интерфейс пользователя с машиной.

В чём проблема? есть железка. У неё есть устройство ввода. Кто-то же должен оное обслуживать и посылать данные о нажатии кнопок приложению-клиенту оконной системы.

Собственно, если иксы контролируют _весь_ ввод, доступный приложениям (как ни на что не годный core, так и всякие xinput2), нафиг им слать события куда-то наружу? Они могут слать события любому окну и без этого.

Ну и в чём тогда проблема с виртуальной клавиатурой?